From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
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-26 00:58:47 |
Message-ID: | 27844.1301101127@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mar 25, 2011, at 7:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Well, maybe, but it's not like it's subtle or hard to fix.
> Depends how much of it you have. I've become very skeptical of
> anything that breaks pg_dump-and-reload-ability.
This wouldn't break pg_dump scripts, because they disable
check_function_bodies. You would get a failure on first *use*
of a function, which is something different.
Basically my concern here is that in the name of easing a short-term
conversion issue, we'll be condemning users to a future of subtle,
hard-to-find bugs due to ambiguous names. How many hundreds of
reports have we seen about the equivalent problem in plpgsql?
You could argue that the frequency of plpgsql issues was at least partly
due to having a poor choice of which way to resolve the ambiguity, but
I don't think it can be entirely blamed on that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua Berkus | 2011-03-26 01:05:45 | Re: GSoC 2011 - Mentors? Projects? |
Previous Message | Tomas Vondra | 2011-03-26 00:50:53 | Re: GSoC 2011 - Mentors? Projects? |