Re: WIP: Allow SQL-language functions to reference parameters by parameter name

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

In response to

Responses

Browse pgsql-hackers by date

  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