[HACKERS] Bug in pg_describe_object (was: Re: [HACKERS] obj_unique_identifier(oid))
Here is the bug-fix patch again with a description of the context so I
can add it to the commit fest.
Joel Jacobson discovered a bug in the function pg_describe_object where
it does not produce unique identifiers for some entries in pg_amproc.
This patch fixes the bug where when two entries in pg_amproc only differ
in amproclefttype or amprocrighttype the same description will be
produced by pg_describe_object, by simply adding the two fields
(amproclefttype, amprocrighttype) to the description.
== Before patch
SELECT pg_describe_object('pg_amproc'::regclass,oid,0)
FROM pg_amproc WHERE oid IN (10608,10612);
pg_describe_object
function 1 bttextcmp(text,text) of operator family array_ops for access method
gin
function 1 bttextcmp(text,text) of operator family array_ops for access method
gin
(2 rows)
== After patch
SELECT pg_describe_object('pg_amproc'::regclass,oid,0)
FROM pg_amproc WHERE oid IN (10608,10612);
pg_describe_object
--
function 1 bttextcmp(text,text) of operator family array_ops for access method
gin for (text[],text[])
function 1 bttextcmp(text,text) of operator family array_ops for access method
gin for (character varying[],character varying[])
(2 rows)
Regards,
Andreas
diff --git a/src/backend/catalog/dependency.c b/src/backend/catalog/dependency.c
index ec8eb74..795051e 100644
*** a/src/backend/catalog/dependency.c
--- b/src/backend/catalog/dependency.c
*** getObjectDescription(const ObjectAddress
*** 2389,2398
* textual form of the function with arguments, and the second
* %s is the description of the operator family.
*/
! appendStringInfo(buffer, _(function %d %s of %s),
amprocForm-amprocnum,
format_procedure(amprocForm-amproc),
! opfam.data);
pfree(opfam.data);
systable_endscan(amscan);
--- 2389,2400
* textual form of the function with arguments, and the second
* %s is the description of the operator family.
*/
! appendStringInfo(buffer, _(function %d %s of %s for (%s,%s)),
amprocForm-amprocnum,
format_procedure(amprocForm-amproc),
! opfam.data,
! format_type_be(amprocForm-amproclefttype),
! format_type_be(amprocForm-amprocrighttype));
pfree(opfam.data);
systable_endscan(amscan);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in pg_describe_object (was: Re: [HACKERS] obj_unique_identifier(oid))
2011/1/10 Andreas Karlsson andr...@proxel.se: Here is the bug-fix patch again with a description of the context so I can add it to the commit fest. Many thanks for fixing the bug! I also implemented the pg_describe_object in pure SQL, for those of us who have not yet switched to PostgreSQL 9 in the production. Very helpful function indeed! https://github.com/gluefinance/pov/blob/master/sql/schema/pov/functions/pg_describe_object.sql -- Best regards, Joel Jacobson Glue Finance -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in pg_describe_object (was: Re: [HACKERS] obj_unique_identifier(oid))
Andreas Karlsson andr...@proxel.se writes: Here is the bug-fix patch again with a description of the context so I can add it to the commit fest. Joel Jacobson discovered a bug in the function pg_describe_object where it does not produce unique identifiers for some entries in pg_amproc. There was never any intention that that code produce a guaranteed-unique identifier; it's only meant to be a humanly useful identifer, and this patch seems to me to mostly add noise. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in pg_describe_object (was: Re: [HACKERS] obj_unique_identifier(oid))
2011/1/10 Tom Lane t...@sss.pgh.pa.us: There was never any intention that that code produce a guaranteed-unique identifier; it's only meant to be a humanly useful identifer, and this patch seems to me to mostly add noise. For all objects, except for these pg_amproc regclass, the function does already generate unique strings. They are guaranteed to be unique thanks to every component of the unique constraints in alll pg_* tables are included in the unique text identifier. It makes a lot more sense to fix the function to return a unique string also for pg_amproc, than to introduce a entirely new function which returns a unique string identifier. It would hardly break anything and I think you exaggerate the noise factor. I can think of numerous reasons why it is absolutely necessary to provide a function generating unique identifiers for objects: a) To allow comparing all objects in two different databases, by comparing objects with the same identifier. This cannot be done using the oids, since they naturally differ between databases. b) To draw nice human readable digraphs in the .dot format , instead of drawing relations digraphs of classid.objid.subobjid. c) OIDs are probably misused in a lot of applications, due to misunderstandings of what they are and not are, I for one didn't know they are not necessarily unique, but only within their regclass. It would be better to encourage users to use a text string if they need to refer to a unique objects in their application, than to force them to use OIDs (or in combination with the regclass, almost as bad), in lack of something better. While you could build your own query to generate a unique string, based on all the columns defining the unique constraint for each class, doing so is very cumbersome and requires a lot of postgres-guru-knowledge. I think it would be a big improvement and increase the number of possible use cases of the existing pg_describe_object function if the documentation would say the returned text is guaranteed to be unique for each object. -- Best regards, Joel Jacobson Glue Finance E: j...@gluefinance.com T: +46 70 360 38 01 Postal address: Glue Finance AB Box 549 114 11 Stockholm Sweden Visiting address: Glue Finance AB Birger Jarlsgatan 14 114 34 Stockholm Sweden -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
