Re: [BUGS] BUG #5629: ALTER SEQUENCE foo START execute a RESTART
Tom Lane escreveu: > I'm not inclined to go and retroactively document that these spellings > are possible but deprecated in the old branches. I think that would > just confuse matters even more. > Is it worth preventing that sloppy implementation in the old branches? -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] issue about information_schema REFERENTIAL_CONSTRAINTS
Dear Tom, The REFERENTIAL_CONSTRAINTS table in the information_schema references a constaint through its database/schema/name, but this information is not unique, so it may identify several constraints, thus the information derived may not be consistent. Postgres does not enforce that constraints have unique names within a schema. The SQL spec does say that they should be unique per-schema, and the information_schema views are designed on that assumption. Hence a contradiction. If you use spec-compliant names for your constraints, you won't have a problem. If you don't, well, the information_schema views will be of limited use to you. I'm writing a schema analyzer which gives false results. I do not write the constraints, I'm analyzing existing schemas. I cannot change it. Suggestion: constraint names could be systematically prefixed with their corresponding table so that they are indeed unique, We are not going to try to enforce uniqueness. I'm not asking for uniqueness in "pg_catalog", esp as that would break existing applications. I'm suggesting uniqueness in the "information_schema", which can be provided independently by some tweaking in the view construction, I think, for instance by adding the oid of the constraint or maybe the table_name. This has been debated before, and most people like the current behavior just fine, or at least better than the alternatives. I do not know "most people". I guess "most people" just do not use the "information_schema", so they really do not care! For the "few people" who do use the information_schema, I can assure you that having a false information is a severe drawback, and it is called a "bug". So at least please fill in this as a "bug" somewhere, even if you do not want to fix it. -- Fabien. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] issue about information_schema REFERENTIAL_CONSTRAINTS
On ons, 2010-09-01 at 16:22 +0200, Fabien COELHO wrote: > I'm suggesting uniqueness in the "information_schema", which can be > provided independently by some tweaking in the view construction, I > think, for instance by adding the oid of the constraint or maybe the > table_name. The view is defined by the SQL standard. We cannot change it. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Exclude constraint problem
Well, the answer is that Jeff's instinct was right: the dump and reload isn't reproducing the original data exactly. It's not our fault though, it's a postgis bug. Observe: gisttest2=# select ST_expand(setsrid(makepoint(-122.50367,37.74189),4326), 0.4); st_expand 010320E61001000500C32ADEC83CA05EC0D044D8F0F4DE4240C32ADEC83CA05EC0ECF5EE8FF7DE424035D252793BA05EC0ECF5EE8FF7DE424035D252793BA05EC0D044D8F0F4DE4240C32ADEC83CA05EC0D044D8F0F4DE4240 (1 row) gisttest2=# select ST_expand(setsrid(makepoint(-122.50376,37.74185),4326), 0.4); st_expand 010320E6100100050063EE5A423EA05EC042EC4CA1F3DE424063EE5A423EA05EC05E9D6340F6DE4240D595CFF23CA05EC05E9D6340F6DE4240D595CFF23CA05EC042EC4CA1F3DE424063EE5A423EA05EC042EC4CA1F3DE4240 (1 row) gisttest2=# select ST_expand(setsrid(makepoint(-122.50367,37.74189),4326), 0.4) && ST_expand(setsrid(makepoint(-122.50376,37.74185),4326), 0.4); ?column? -- f (1 row) gisttest2=# select '010320E61001000500C32ADEC83CA05EC0D044D8F0F4DE4240C32ADEC83CA05EC0ECF5EE8FF7DE424035D252793BA05EC0ECF5EE8FF7DE424035D252793BA05EC0D044D8F0F4DE4240C32ADEC83CA05EC0D044D8F0F4DE4240'::geometry && gisttest2-# '010320E6100100050063EE5A423EA05EC042EC4CA1F3DE424063EE5A423EA05EC05E9D6340F6DE4240D595CFF23CA05EC05E9D6340F6DE4240D595CFF23CA05EC042EC4CA1F3DE424063EE5A423EA05EC042EC4CA1F3DE4240'::geometry; ?column? -- t (1 row) So these two geometry values do not overlap in the original database, but they do overlap in the clone, apparently because the output representation of geometry doesn't result in an exact reconstruction of the value. Somebody better complain over in the postgis lists. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Exclude constraint problem
Tom Lane wrote: So these two geometry values do not overlap in the original database, but they do overlap in the clone, apparently because the output representation of geometry doesn't result in an exact reconstruction of the value. Somebody better complain over in the postgis lists. Thanks for doing all of that leg work. Whinging has commenced. - alex -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5629: ALTER SEQUENCE foo START execute a RESTART
Excerpts from Euler Taveira de Oliveira's message of mié sep 01 10:18:10 -0400 2010: > Tom Lane escreveu: > > I'm not inclined to go and retroactively document that these spellings > > are possible but deprecated in the old branches. I think that would > > just confuse matters even more. > > Is it worth preventing that sloppy implementation in the old branches? That risks removing a (mis)feature that people are currently depending on. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] issue about information_schema REFERENTIAL_CONSTRAINTS
Dear Peter, I'm suggesting uniqueness in the "information_schema", which can be provided independently by some tweaking in the view construction, I think, for instance by adding the oid of the constraint or maybe the table_name. The view is defined by the SQL standard. No. The result of the view (the definition of the expected attributes) is defined in the standard. But it is really a view on top of "pg_catalog". You are right that some views of the information_schema are defined in the standard, but they deal with restrictions of other relations, say the privileges for the current user... We cannot change it. Yes we can! It, it is 100% postgresql: \d information_schema.referential_constraints View "information_schema.referential_constraints" ... FROM pg_namespace ncon JOIN pg_constraint con ON ncon.oid = con.connamespace JOIN pg_class c ON con.conrelid = c.oid -- Fabien Coelho - CRI, Maths & Systèmes, MINES ParisTech -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
