Re: [rfc] new CREATE FUNCTION (and more) - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: [rfc] new CREATE FUNCTION (and more)
Date
Msg-id 20001116192437.A9256@l-t.ee
Whole thread Raw
In response to Re: [rfc] new CREATE FUNCTION (and more)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Nov 16, 2000 at 11:20:58AM -0500, Tom Lane wrote:
> Marko Kreen <marko@l-t.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.

Hmm.  I think I have to agree.  The thing is I did all-powerful
CREATE FUNCTION, then I noticed that the module-provided-info
stuff is separate functionality and split them off into LOAD *
functions.  So I did not noticed that the remaining CREATE
FUNCTION has not much point anymore...  :)

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

Ok.  I only want to note that the "newC" interface  is "good" in
the sense that it probably stays around a long time.  It would
be nice if the name seems reasonable after a couple of years
too. But I better shut up on this issue now.

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

Yes.  

> 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.)

Embedded stuff makes the handling less error-prone and
comfortable.  Makefiles too dont bring any new functionality
to the program being compiled... :)

But I think that "LOAD MODULE" starts bringing new functionality
but what exactly I do not know yet...

-- 
marko



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [rfc] new CREATE FUNCTION (and more)
Next
From: Larry Rosenman
Date:
Subject: coding style guidelines?