From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Matthew Draper <matthew(at)trebex(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP: Allow SQL-language functions to reference parameters by parameter name |
Date: | 2011-03-25 20:20:03 |
Message-ID: | 15775.1301084403@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:
> 2011/3/25 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> I think the best idea is to throw error for ambiguous references,
>> period.
> There can be GUC for controlling use or don't use a parameter names. I
> am for GUC, because there will be a bilion conflicts. But a talk about
> priorities - sql identifier or parameter is useless.
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. The
mess and complication we have for the comparable behavior in plpgsql
seemed necessary because of the number of existing usages that would
certainly break --- but I doubt that SQL-language functions will have
anywhere near as big a problem.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-03-25 20:21:03 | Re: Pre-set Hint bits/VACUUM FREEZE on data load..? |
Previous Message | Robert Haas | 2011-03-25 20:18:00 | Re: Set hint bits upon eviction from BufMgr |