Re: pg_dump: CREATE TABLE + CREATE RULE vs. relreplident

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Marko Tiikkaja <marko(at)joh(dot)to>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump: CREATE TABLE + CREATE RULE vs. relreplident
Date: 2015-03-12 15:32:22
Message-ID: 87mw3iqm3d.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

>> I've wondered for a while whether this wouldn't have been better
>> handled as:

>> create view qwr(colnames...) as select null::type1, null::type2, ...;
>> /* ... */
>> create or replace view qwr as ...;

Tom> Yeah, possibly. The existing pg_dump coding dates from before we
Tom> had CREATE OR REPLACE VIEW.

As it happens it does not; the issue came up originally because of a
hack I came up with, and I've never used any pg version so old it didn't
have CREATE OR REPLACE VIEW. Nor does it look like the change was ever
backpatched (or at least not that far).

http://www.postgresql.org/message-id/20986.1102296367@sss.pgh.pa.us

Of course, at the time I myself didn't think of using a view rather than
a table for the initial creation; I was focused on rules because that
was the only way to get updateable views then. So arguably it is at
least partly my fault.

Tom> But we'll have to live with pg_dump files that do this for the
Tom> indefinite future, so I agree some fix is needed on the backend
Tom> side.

Certainly.

--
Andrew (irc:RhodiumToad)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-03-12 15:50:56 Re: EvalPlanQual behaves oddly for FDW queries involving system columns
Previous Message Amit Kapila 2015-03-12 15:29:32 Re: Parallel Seq Scan