From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Abhijit Menon-Sen <ams(at)oryx(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Allow COMMENT ON to accept an expression rather than just a string |
Date: | 2009-04-11 18:44:39 |
Message-ID: | 3973.1239475479@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 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 || '(....
I was intentionally excluding the idea of substituting parameters for
names as opposed to constants. For one thing it's fundamentally
ambiguous --- given
string_var := 'foo';
EXECUTE 'SELECT $1 FROM bar' USING string_var;
is that supposed to mean SELECT 'foo' FROM bar or SELECT foo FROM bar?
The other problem is that if you allow name substitution it becomes
entirely impossible to do any planning or even validity checking before
the parameter values are available. So while string assembly is kind
of a pain in the rear when you really do need a dynamic name reference,
I think we should keep it firmly separate from parameter substitution.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2009-04-11 18:46:23 | Re: Allow COMMENT ON to accept an expression rather than just a string |
Previous Message | Josh Berkus | 2009-04-11 18:40:57 | Re: Allow COMMENT ON to accept an expression rather than just a string |