Re: [rfc] new CREATE FUNCTION (and more)
От | Marko Kreen |
---|---|
Тема | Re: [rfc] new CREATE FUNCTION (and more) |
Дата | |
Msg-id | 20001116192437.A9256@l-t.ee обсуждение исходный текст |
Ответ на | Re: [rfc] new CREATE FUNCTION (and more) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: