Re: insufficient qualification of some objects in dump files

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: insufficient qualification of some objects in dump files
Date: 2016-02-26 06:15:13
Message-ID: CAB7nPqSUbQmeMPBcyq_zTZHbrscCta4r1FLBrHse8cjNRxKdpg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 26, 2016 at 9:47 AM, Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-02-26 06:21:22 Re: FDW handling count(*) through AnalyzeForeignTable or other constant time push-down
Previous Message Amit Langote 2016-02-26 06:05:08 Re: Declarative partitioning