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