Re: WIP: Allow SQL-language functions to reference parameters by parameter name - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: WIP: Allow SQL-language functions to reference parameters by parameter name
Date
Msg-id AANLkTikF1EEw+RCwHSoX-kjneBvTxOLaXF9GUw6UP-SZ@mail.gmail.com
Whole thread Raw
In response to Re: WIP: Allow SQL-language functions to reference parameters by parameter name  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2011/3/25 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2011/3/25 Tom Lane <tgl@sss.pgh.pa.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.

should be nice some converting tool for pg_dump or pg_upgrade. It can
dump SQL functions with only qualified identifiers.

Pavel

>
>                        regards, tom lane
>


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Transactional DDL, but not Serializable
Next
From: Tom Lane
Date:
Subject: Re: Transactional DDL, but not Serializable