Re: insufficient qualification of some objects in dump files

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: insufficient qualification of some objects in dump files
Дата
Msg-id CAB7nPqSUbQmeMPBcyq_zTZHbrscCta4r1FLBrHse8cjNRxKdpg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: insufficient qualification of some objects in dump files  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: insufficient qualification of some objects in dump files  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: Declarative partitioning
Следующее
От: Tom Lane
Дата:
Сообщение: Re: FDW handling count(*) through AnalyzeForeignTable or other constant time push-down