On Fri, Apr 8, 2011 at 3:56 PM, Josh Berkus <j...@agliodbs.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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to