From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Stephen Cuppett <steve(at)cuppett(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Trouble using TG_TABLE_NAME in BEFORE INSERT OR UPDATE trigger |
Date: | 2009-08-30 13:37:38 |
Message-ID: | 20090830133738.GB31690@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, Aug 30, 2009 at 03:22:16PM +0200, Pavel Stehule wrote:
> Hello
>
> you cannot use variable as table or column name in direct query.
>
> look on execute statemen:
> http://www.postgresql.org/docs/8.4/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-EXECUTING-DYN
>
> or don't use generic triggers.
You know, it would be really nice to have a way of dealing with this. I
was thinking, just like we have the OPERATOR() keyword for tokens that
wouldn't normally be considered operators, we could use TABLE() to
introduce table name where they wouldn't normally be recognised. Like:
SELECT a FROM TABLE($1);
TABLE is a reserved word, so there doesn't appear to be a backward
compatability problem. The argument would have to be a text constant,
or a bind parameter. Sure, it would disable query caching, but the
benefits in clarity seem worth it.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2009-08-30 14:09:23 | Re: Trouble using TG_TABLE_NAME in BEFORE INSERT OR UPDATE trigger |
Previous Message | Pavel Stehule | 2009-08-30 13:22:16 | Re: Trouble using TG_TABLE_NAME in BEFORE INSERT OR UPDATE trigger |