On Sat, Nov 11, 2000 at 08:30:48PM -0500, Tom Lane wrote:
> Philip Warner <pjw@rhyme.com.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
