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

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: pg_dump: CREATE TABLE + CREATE RULE vs. relreplident
Дата
Msg-id 87mw3iqm3d.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: pg_dump: CREATE TABLE + CREATE RULE vs. relreplident  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_dump: CREATE TABLE + CREATE RULE vs. relreplident  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: pg_dump: CREATE TABLE + CREATE RULE vs. relreplident  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Parallel Seq Scan
Следующее
От: Tom Lane
Дата:
Сообщение: Re: EvalPlanQual behaves oddly for FDW queries involving system columns