Re: insufficient qualification of some objects in dump files - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: insufficient qualification of some objects in dump files
Date
Msg-id CAB7nPqSUbQmeMPBcyq_zTZHbrscCta4r1FLBrHse8cjNRxKdpg@mail.gmail.com
Whole thread Raw
In response to Re: insufficient qualification of some objects in dump files  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: insufficient qualification of some objects in dump files
List pgsql-hackers
On Fri, Feb 26, 2016 at 9:47 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On 1/29/16 1:24 AM, Michael Paquier wrote:
>>> I think we should amend the archive tag for these kinds of objects to
>>> > include the table name, so it might look like:
>>> >
>>> > 2153; 2604 39696 DEFAULT public test a rolename
>>> >
>>> > Comments?
>> +1. I noticed that this limitation is present for triggers (as you
>> mentioned), constraints, fk constraints and RLS policies which should
>> be completed with a table name.
>
> Thank you for collecting this list.  Attached is a patch for this.

Visibly rules are on the stack as well, I forgot to mention them, and
your updated patch does the job correctly.

> Tom thought this might require an archive version dump, but I'm not
> sure.  The tags are more of an informational string for human
> consumption, not strictly part of the archive format.

Hm, the TOC entry, with its tag changed, is part of the dump, and this
is written in the archive, but the shape of TocEntry does not change
so this is really debatable. It is true that pg_restore -L is able to
work even if the tag output is changed, still now that I think about
that a version bump would be preferrable: what is generated by the
bump is changed after all. The previous version upgrades that are
K_VERS_1_11 or K_VERS_1_6 working on TOC did add new fields in the
structure TocEntry and influenced pg_restore.
-- 
Michael



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Declarative partitioning
Next
From: Tom Lane
Date:
Subject: Re: FDW handling count(*) through AnalyzeForeignTable or other constant time push-down