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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026