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

On Fri, Apr 8, 2011 at 3:56 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> But breaking people's code is not a better answer.  We still
>> have people on 8.2 because the pain of upgrading to 8.3 is more than
>> they can bear, and how many releases have we spent trying to get
>> standard_conforming_strings worked out?  I admit this probably
>> wouldn't be as bad, but we've managed to put out several releases in a
>> row now that are relatively painless to upgrade between, and I think
>> that's a trend we should try to keep going.
>
> I guess I'm not understanding the backwards compatibility problem.  I've
> looked up the thread, and I still don't see a real-world issue.  If we
> (by default) throw an error on ambiguity, and have GUC to turn that off
> (in which case, it resolves column-first), I really don't see what
> problem anyone could have upgrading.
>
> Can you explain it to me?

Consider:

rhaas=# CREATE TABLE developer (id serial primary key, name text not null);
NOTICE: CREATE TABLE will create implicit sequence "developer_id_seq"
for serial column "developer.id"
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"developer_pkey" for table "developer"
CREATE TABLE
rhaas=# insert into developer (name) values ('Tom'), ('Bruce');
INSERT 0 2
rhaas=# CREATE OR REPLACE FUNCTION developer_lookup(id integer)
RETURNS text AS $$SELECT name FROM developer WHERE id = $1$$ LANGUAGE
sql STABLE;
CREATE FUNCTION
rhaas=# SELECT developer_lookup(1);
developer_lookup
------------------
Tom
(1 row)

Now, when this person attempts to recreate this function on a
hypothetical version of PostgreSQL that thinks "id" is ambiguous, it
doesn't work.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company