Re: [HACKERS] pg_dump versus rules, once again

2016-12-30 Thread Benedikt Grundmann
On 30 December 2016 at 11:58, Benedikt Grundmann wrote: > > On 17 November 2016 at 03:45, Robert Haas wrote: > >> On Wed, Nov 16, 2016 at 10:14 PM, Tom Lane wrote: >> > Robert Haas writes: >> >> On Wed, Nov 16, 2016 at 10:00 PM, Tom Lane wrote: >> >>> The changes in pg_backup_archiver.c would

Re: [HACKERS] pg_dump versus rules, once again

2016-12-30 Thread Benedikt Grundmann
On 17 November 2016 at 03:45, Robert Haas wrote: > On Wed, Nov 16, 2016 at 10:14 PM, Tom Lane wrote: > > Robert Haas writes: > >> On Wed, Nov 16, 2016 at 10:00 PM, Tom Lane wrote: > >>> The changes in pg_backup_archiver.c would have to be back-patched > >>> into all versions supporting --if-ex

Re: [HACKERS] pg_dump versus rules, once again

2016-11-16 Thread Robert Haas
On Wed, Nov 16, 2016 at 10:14 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Nov 16, 2016 at 10:00 PM, Tom Lane wrote: >>> The changes in pg_backup_archiver.c would have to be back-patched >>> into all versions supporting --if-exists, so that they don't fail >>> on dump archives produced b

Re: [HACKERS] pg_dump versus rules, once again

2016-11-16 Thread Tom Lane
Robert Haas writes: > On Wed, Nov 16, 2016 at 10:00 PM, Tom Lane wrote: >> The changes in pg_backup_archiver.c would have to be back-patched >> into all versions supporting --if-exists, so that they don't fail >> on dump archives produced by patched versions. > Even if you patch future minor rel

Re: [HACKERS] pg_dump versus rules, once again

2016-11-16 Thread Robert Haas
On Wed, Nov 16, 2016 at 10:00 PM, Tom Lane wrote: > The changes in pg_backup_archiver.c would have to be back-patched > into all versions supporting --if-exists, so that they don't fail > on dump archives produced by patched versions. Even if you patch future minor releases, past minor releases a

Re: [HACKERS] pg_dump versus rules, once again

2016-11-16 Thread Tom Lane
I wrote: > We've talked before about replacing this _RETURN-rule business with > CREATE OR REPLACE VIEW, ie the idea would be for pg_dump to first emit > a dummy view with the right column names/types, say > CREATE VIEW vv AS SELECT null::int AS f1, null::text AS f2; > and then later when it's safe

[HACKERS] pg_dump versus rules, once again

2016-11-16 Thread Tom Lane
I looked into the problem reported at https://www.postgresql.org/message-id/b3690957-fd8c-6def-d3ec-e589887dd0f1%40codata.eu It's easy to reproduce. Given this simple database: create table tt (f1 int primary key, f2 text); create view vv as select * from tt group by f1; pg_dump with the --clea