Re: [rfc] new CREATE FUNCTION (and more)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marko Kreen <marko(at)l-t(dot)ee>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [rfc] new CREATE FUNCTION (and more)
Date: 2000-11-16 16:20:58
Message-ID: 1342.974391658@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marko Kreen <marko(at)l-t(dot)ee> writes:
> This mostly like the current "CREATE FUNCTION .. LANGUAGE 'C'".
> Main difference is that the TYPE=0 means the old 'C' interface
> and TYPE=1 means 'newC' interface. Default is 1.

This improves matters how, exactly? As far as I can see, this just
replaces a readable construct with magic numbers, for a net loss in
readability and no change in functionality.

I don't have any great love for the names 'C' and 'newC' either, but
unless we are willing to break backward-compatibility of function
declarations in 7.1, I think we are stuck with those names or ones
isomorphic to them.

In the long run, it seems that it'd be a good idea to embed function
declaration info straight into a loadable module, per Philip's idea
of a special function or your idea of a table. However that does not
change the issue of names for function-call conventions in the least,
it merely avoids the problem of keeping a script of SQL declarations
in sync with the library file. (One brain-dead-simple definition of
the info function or table is that it returns/contains a text string
that's exactly the SQL commands needed to create the function
definitions, except we could allow them to omit the pathname
of the library file. We can probably do better than that, but as
far as raw functionality goes, that will accomplish everything that
a fancier-looking API would do.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-11-16 16:59:08 Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Previous Message Ross J. Reedstrom 2000-11-16 15:59:26 Re: Coping with 'C' vs 'newC' function language namesh