Re: [BUGS] BUG #7486: Error Group by
On Fri, Aug 10, 2012 at 10:33 AM, wrote: > The following bug has been logged on the website: > > Bug reference: 7486 > Logged by: Anderson Abreu > Email address: andersonab...@gmail.com > PostgreSQL version: 8.4.12 > Operating system: Linux > Description: > > Dear, > > I'm test the script, for example: select attA, attB from table1 group by > attA. > > In postgre 8.4.X show error column attB must appear in the GROUP BY clause > or be used in an aggregate function. > > But, in postgre 9.1.X the query running sucesfully. > > Why? attA is probably a primary key, is that the case? http://www.postgresql.org/docs/9.1/static/release-9-1.html#AEN107670 "Allow non-GROUP BY columns in the query target list when the primary key is specified in the GROUP BY clause (Peter Eisentraut) The SQL standard allows this behavior, and because of the primary key, the result is unambiguous." -- fdr - Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Bug when changing datatype of primary key column
tested on: 1. 9.1.3 2. 9.3devel (yesterdays head in git) steps to reproduce: $ create table z (i int4); CREATE TABLE $ create unique index q on z (i); CREATE INDEX $ alter table z add primary key using index q; ALTER TABLE $ alter table z alter column i type int8; ERROR: could not open relation with OID 16503 looks like some missing dependancy. Best regards, depesz -- The best thing about modern society is how easy it is to avoid contact with it. http://depesz.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] Bug when changing datatype of primary key column
hubert depesz lubaczewski writes: > $ create table z (i int4); > CREATE TABLE > $ create unique index q on z (i); > CREATE INDEX > $ alter table z add primary key using index q; > ALTER TABLE > $ alter table z alter column i type int8; > ERROR: could not open relation with OID 16503 > looks like some missing dependancy. Mph. Looks more like too many dependencies :-( If you just create a pkey straight off, the dependencies look like this: regression=# create domain ref as int; CREATE DOMAIN regression=# create table z (i int primary key); CREATE TABLE regression=# select pg_describe_object(classid,objid,objsubid) as obj, pg_describe_object(refclassid,refobjid,refobjsubid) as ref, deptype from pg_depend where objid > 'ref'::regtype or refobjid > 'ref'::regtype; obj | ref | deptype --+--+- type z | table z | i type z[] | type z | i table z | schema public| n constraint z_pkey on table z | table z column i | a index z_pkey | constraint z_pkey on table z | i (5 rows) But if you make the index separately and then use "add primary key using index": regression=# drop table z; DROP TABLE regression=# create table z (i int4); CREATE TABLE regression=# create unique index q on z (i); CREATE INDEX regression=# select pg_describe_object(classid,objid,objsubid) as obj, pg_describe_object(refclassid,refobjid,refobjsubid) as ref, deptype from pg_depend where objid > 'ref'::regtype or refobjid > 'ref'::regtype; obj| ref| deptype --+--+- type z | table z | i type z[] | type z | i table z | schema public| n index q | table z column i | a (4 rows) regression=# alter table z add primary key using index q; ALTER TABLE regression=# select pg_describe_object(classid,objid,objsubid) as obj, pg_describe_object(refclassid,refobjid,refobjsubid) as ref, deptype from pg_depend where objid > 'ref'::regtype or refobjid > 'ref'::regtype; obj | ref | deptype -+-+- type z | table z | i type z[]| type z | i table z | schema public | n index q | table z column i| a constraint q on table z | table z column i| a index q | constraint q on table z | i (6 rows) So that ALTER is forgetting to remove the index's original direct dependency on the table column(s). I suppose ideally that wouldn't matter, but in the real world it will likely confuse many things, not just ALTER COLUMN TYPE. 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
[BUGS] pg_dump dependency loop with extension containing its own schema
Hi, I'm getting a dependency loop issue with pg_dump when adding a schema to an extension where the schema being added is the same as the one containing the extension. CREATE EXTENSION file_fdw; ALTER EXTENSION file_fdw ADD SCHEMA public; $ pg_dump -f /dev/null test pg_dump: [sorter] WARNING: could not resolve dependency loop among these items: pg_dump: [sorter] SCHEMA public (ID 5 OID 2200) pg_dump: [sorter] EXTENSION file_fdw (ID 170 OID 28912) or CREATE SCHEMA meow; CREATE EXTENSION file_fdw WITH SCHEMA meow; ALTER EXTENSION file_fdw ADD SCHEMA meow; $ pg_dump -f /dev/null test pg_dump: [sorter] WARNING: could not resolve dependency loop among these items: pg_dump: [sorter] SCHEMA meow (ID 7 OID 28917) pg_dump: [sorter] EXTENSION file_fdw (ID 171 OID 28918) but not CREATE SCHEMA meow; CREATE EXTENSION file_fdw WITH SCHEMA meow; ALTER EXTENSION file_fdw ADD SCHEMA public; $ pg_dump -f /dev/null test3 $ (no errors shown) I can produce this issue in 9.1.4 and head (as of commit 83af58f6b5657840f5924332fccecca1e3556abe). Since this is a bug report, I'll include the necessary supporting info: OS: Linux Mint x64 Kernel: 3.2.0-27-generic CC version: Linaro 4.6.3-1ubuntu5 RAM: 16GB DDR3 -- Thom - 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] pg_dump dependency loop with extension containing its own schema
Thom Brown writes: > I'm getting a dependency loop issue with pg_dump when adding a schema > to an extension where the schema being added is the same as the one > containing the extension. > CREATE EXTENSION file_fdw; > ALTER EXTENSION file_fdw ADD SCHEMA public; ISTM we ought to disallow that ... either the schema is inside the extension, or vice versa, it's not sensible to say both. 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
