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

> > No.  'C' is really a misnomer, since it does NOT imply anything about
> > whether the code is in C or not --- in theory you could use any language
> > that's link-compatible with C.  What LANGUAGE 'C' really implies is
> > "dynamically linked, compiled function following fmgr interface
> > convention #1"", as opposed to (for example) LANGUAGE 'internal' which
> > implies "statically linked, compiled function following fmgr interface
> > convention #1".  Nothing about language at all.
> 
> Maybe the construct
> 
>   CREATE FUNCTION foo(..) RETURNS ...
>   AS '../foo.so' LANGUAGE 'C';
> 
> would be cleaner as
> 
>   CREATE FUNCTION foo(..) RETURNS ...
>   FROM '../foo.so', 'pg_foo' [[WITH] VERSION abi_ver];
> 
> or with more noise:
>         
>   FROM [LIBRARY] '../foo.so' AS 'pg_foo' [[WITH] VERSION abi_ver];
> 
> because as said, it can be any other language besides C and also
> the 'AS file' is weird.

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.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026