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

On Sat, Nov 11, 2000 at 08:30:48PM -0500, Tom Lane wrote:
> Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:

...

> > It does avoid "language 'evenNewerC'" in the furture.
>
> How so? It appears to me it would just move the 'evenNewerFoo'
> dirtiness to a different keyword, which would still be essential
> for the user to write. Net result: no gain, just more writing.
>
> > By allowing optional
> > attributes to use older fmgr interfaces we preserve compatibility without
> > cluttering the list of languages. From the developer/user point of view,
> > the language is 'C' if it's written in C.
>
> 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.

--
marko