> 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
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
