Re: pg_dump: CREATE TABLE + CREATE RULE vs. relreplident - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: pg_dump: CREATE TABLE + CREATE RULE vs. relreplident
Date
Msg-id 87mw3iqm3d.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: pg_dump: CREATE TABLE + CREATE RULE vs. relreplident  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump: CREATE TABLE + CREATE RULE vs. relreplident
Re: pg_dump: CREATE TABLE + CREATE RULE vs. relreplident
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.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 weTom> 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 theTom> indefinite future, so I agree some fix is
neededon the backendTom> side.
 

Certainly.

-- 
Andrew (irc:RhodiumToad)



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Parallel Seq Scan
Next
From: Tom Lane
Date:
Subject: Re: EvalPlanQual behaves oddly for FDW queries involving system columns