Re: Coping with 'C' vs 'newC' function language namesh

At 23:42 15/11/00 -0500, Bruce Momjian wrote:
>> To answer another misconception that I saw in this thread:
>>
>> : The old language names "internal" and "C" will continue to refer to
>> : functions with the old calling convention. We should deprecate
>> : old-style functions because of their portability problems, but the
>> : support for them will only be one small function handler routine,
>> : so we can leave them in place for as long as necessary.
>
>My question is can we drop newC and use just plain C in 7.2 or 7.3?

I plan to work on a a proposal for a (hopefully) version independant
function manager interface; the idea behind the proposal is to allow PGSQL
to query the modules for information about the functions, but calling a
single known entry point. The information stored in the database relation
would be substantially reduced, and the backends would load the module then
enquire about the functions, storing the results in memory. The kind of SQL
required would be:

Create Function foo(int4, int4) from library 'path-to-lib';

and possibly,

Create Module foo_mod from library 'path-to-lib';

The idea being to only store whe function signature and enough details to
get to the info-function. If 'Create Module' were allowed, then it would
automatically create appropriate function definitions when the statement
was executed.

The info-function would return data in a struct passed from the backend,
and part of the struct would include version information. The backend would
then be responsible for handling new & old protocols.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/