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