Re: Allow COMMENT ON to accept an expression rather than just a string

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

In response to

Responses

Browse pgsql-hackers by date

  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