Re: [HACKERS] dump a comment of a TSDictionary - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] dump a comment of a TSDictionary
Date
Msg-id 26976.1488834059@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] dump a comment of a TSDictionary  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [HACKERS] dump a comment of a TSDictionary  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Giuseppe Broccolo (giuseppe.broccolo@2ndquadrant.it) wrote:
>> I've seen that pg_dump execute the dump of an eventual comment of a
>> TSDictionary without specifying the namespace where it is defined:

> Great catch!

One of my smarter CS professors taught me that whenever you find a bug,
you should look around to see where else you made the same mistake.
Checking for other errors of the same ilk is depressingly fruitful :-(
It looks to me like operator classes, operator families, and all four
types of text-search objects have this same error, and have for a long
time.  I'm also wondering if it wouldn't be wise for the dumpComment()
call for procedural languages to use "lanschema", so that the comment
TocEntry matches the parent object in both cases for PL objects.

I'm also kind of wondering why the ArchiveEntry() calls for casts and
transforms specify "pg_catalog" as the schema but we don't do that in
their dumpComment() calls.  Maybe we don't need that hack and should
specify NULL instead.

> Right.  I've got a few other patches queued up for pg_dump, so I'll
> take care of this also.

Do you want to deal with this whole mess, or shall I have a go at it?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Performance degradation in TPC-H Q18
Next
From: Kevin Grittner
Date:
Subject: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed