Re: Allow COMMENT ON to accept an expression rather than just a string
От | Pavel Stehule |
---|---|
Тема | Re: Allow COMMENT ON to accept an expression rather than just a string |
Дата | |
Msg-id | 162867790904111116n5a0779fasd6250298224cae8e@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Allow COMMENT ON to accept an expression rather than just a string (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Allow COMMENT ON to accept an expression rather than just a string
|
Список | pgsql-hackers |
> like (pseudo-code here) > > execute('COMMENT ON foo IS $1', some_string); > > and let the out-of-line-parameter mechanism take care of quoting and > escaping your string. This doesn't work today, and I remember having > seen complaints about that on the JDBC list. So there's a use-case at > least for allowing parameter symbols in place of string literals, if not > fully general expressions. But again, I think we'd want such a thing > across all utility statements that can take string literals, not only > COMMENT. I afraid, this should have some not wanted impacts. When we allows parametrisation in utility statements (and it should be nice), I expect, so there will be people, that will write code like CREATE OR REPLACE FUNCTION some_proc(tabname varchar) RETURNS void AS $$ BEGIN CREATE TABLE tabname(a integer); -- will work INSERT INTO tabname VALUES(10); -- will not work END; $$ LANG .... Now people know, so this cannot do it. But the proc CREATE OR REPLACE FUNCTION some_proc(tabname varchar) RETURNS void AS $$ BEGIN EXECUTE 'CREATE TABLE $1(a integer)' USING tabname; is more readable than EXECUTE 'CREATE TABLE ' || tabname || '(.... so this isn't too simple regards Pavel Stehule > > regards, tom lane >
В списке pgsql-hackers по дате отправления: