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