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

At 21:15 11/11/00 -0500, Bruce Momjian wrote:
>
>This is interesting.  It allows us to control the default behavour of
>"C". I would vote to default to 7.0-style when no version is used for
>7.1, then default to 7.1 style in 7.2 and later.  We don't need
>backward C function compatibility for more than one release, I think.
>

The reason I'd like to see the 'pg_fmgr_info' method in 7.2 is that it will
completely remove any ambiguity from function definitions in the future. 

eg. something like:
 CREATE FUNCTION foo(..) RETURNS ... FROM LIBRARY '../foolib.so';

When a backend *loads* the library file, it would call pg_fmgr_info,
possibly passing the desired function name, and would get in return the
calling semantics (including version information). This would not be stored
in the database, since updates to the object file may change the semantics.

This would make all functions upward compatible. It also has what I
consider a big advantage in that the person who writes the function knows
if it is cacheable, strict etc, and it removes the effective duplication of
effort, not to mention possible errors.

As a final bonus, it makes the following possible:
 CREATE MODULE foomod FROM LIBRARY '../foolib.so';

when this statement is executed, pg_fmgr_info could be called to return a
list of definied functions...for functions created this way, pg_dump would
only need to dump the module definition.




----------------------------------------------------------------
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   |/