From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Matthew Draper <matthew(at)trebex(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: Allow SQL-language functions to reference parameters by parameter name |
Date: | 2011-03-25 22:59:09 |
Message-ID: | FBB8511E-F274-4E0F-86A8-63EFFCC979D7@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mar 25, 2011, at 4:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> GUCs are not tremendously helpful for problems such as this. If we
> actually wanted to preserve full backwards compatibility, we'd need to
> think of a way to mark SQL functions per-function as to what to do.
> But I don't think that's necessary. Up to now there's been relatively
> little use for naming the parameters of SQL functions, so I think there
> will be few conflicts in the field if we just change the behavior.
Oh wow, I don't agree with that at all. People may name the parameters for documentation purposes, and then have things like WHERE foo = $1, foo happening also to be the name associated with $1. Boom!
In any case, I think this is 9.2 material. We need to get a beta out the door, and I emphatically think we should be focusing on resolving the issues with features already committed, not committing new ones.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-03-25 23:45:07 | Re: WIP: Allow SQL-language functions to reference parameters by parameter name |
Previous Message | Tom Lane | 2011-03-25 22:46:50 | Re: locale operation to be invoked, but no collation was derived (in trigger) |