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

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, 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-04-08 03:06:14
Message-ID: 51431AA9-E413-49A2-B63A-5D776A09EE10@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Apr 7, 2011, at 6:58 PM, Tom Lane wrote:

> Well, if we're going to consider 100% backwards compatibility a "must",
> then we should just stick with what the submitted patch does, ie,
> unqualified names are matched first to query columns, and to parameters
> only if there's no column match. This is also per spec if I interpreted
> Peter's comments correctly. The whole thread started because I
> suggested that throwing an error for ambiguous cases might be a better
> design in the long run, but apparently long term ease of code
> maintenance is far down our list of priorities ...

I agree with you that it should throw an error, at least optionally. Could we not recycle the settings that control this for plpgsql functions?

Best,

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-04-08 03:30:50 Re: WIP: Allow SQL-language functions to reference parameters by parameter name
Previous Message Bruce Momjian 2011-04-08 02:21:06 Re: pg_upgrade bug found!