By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,812 Members | 1,978 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,812 IT Pros & Developers. It's quick & easy.

7.3 --> 7.4 C Functions

P: n/a


I'm considering writing some functions in C. This is a collection of
approximately 230 functions, mostly in plpgsql at the moment. Number of lines
of plpgsql is approximately 6500 but that'll include all the blank lines used
for spacing code as well as extra lines to allow nicer formating of things such
as queries. The majority are also not terribly complex involving only a small
number of queries/function calls.

The reasons for changing these to C isn't particularly relevent to the list.
However, all this runs on a 7.3 backend and the priority for changing that is
less that the recoding in C, if that goes ahead. So, what I'm interested in is
people's views on how easy it is to port C functions from 7.3 to 7.4. I know
the elog has changed but that's just a bit of leg work, I presume there is
nothing significant in how to use SPI and the normal sort of tuple manipulation
things.
--
Nigel Andrews

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 12 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
"Nigel J. Andrews" <na******@investsystems.co.uk> writes:
So, what I'm interested in is people's views on how easy it is to port
C functions from 7.3 to 7.4. I know the elog has changed but that's
just a bit of leg work, I presume there is nothing significant in how
to use SPI and the normal sort of tuple manipulation things.


AFAIR the only significant change in stuff that ordinary user-defined
functions might want to use is elog() to ereport(). And even there,
you don't really *have* to convert, it just lets you put out better
error messages.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #2

P: n/a
Nigel J. Andrews wrote:
However, all this runs on a 7.3 backend and the priority for changing that is
less that the recoding in C, if that goes ahead. So, what I'm interested in is
people's views on how easy it is to port C functions from 7.3 to 7.4. I know
the elog has changed but that's just a bit of leg work, I presume there is
nothing significant in how to use SPI and the normal sort of tuple manipulation
things.


I don't think you'll run into too many issues if your needs are simple.
The only thing that I can think of that you might run into is:

7.3 tuplestore_begin_heap(true, SortMem)
7.4 tuplestore_begin_heap(true, false, SortMem)

And that will only apply if you have an SRF that returns a tuplestore
(contrib/tablefunc as an example). You can continue to use elog in 7.4
-- you just don't get to take advantage of the better ereport functionality.

HTH,

Joe

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #3

P: n/a


Thanks chaps. That's exactly what I suspected the case to be.

Now if only that glass of wine hadn't gone straight to my head I could get on
and start the conversion process.
Nigel

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 12 '05 #4

P: n/a
"Nigel J. Andrews" <na******@investsystems.co.uk> writes:
I'm considering writing some functions in C. This is a collection of
approximately 230 functions, mostly in plpgsql at the moment. Number of lines
of plpgsql is approximately 6500


That's a lot of code. A nice thing would be to write a plpgsql -> C
translator (kind of compiler). Many of the requiered work is already
done by the plpgsql handler and it sounds much more fun and useful in
the long term. Just my $0.2.

Regards,
Manuel.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.