Re: more ALTER .. DEPENDS ON EXTENSION fixes - Mailing list pgsql-hackers

From Ahsan Hadi
Subject Re: more ALTER .. DEPENDS ON EXTENSION fixes
Date
Msg-id CA+9bhCLdPQBRDbqBr5Pux9_q7ubz5UtGRzh7sN92tp1NJzmFAA@mail.gmail.com
Whole thread Raw
In response to Re: more ALTER .. DEPENDS ON EXTENSION fixes  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: more ALTER .. DEPENDS ON EXTENSION fixes  (Ibrar Ahmed <ibrar.ahmad@gmail.com>)
Re: more ALTER .. DEPENDS ON EXTENSION fixes  (Ibrar Ahmed <ibrar.ahmad@gmail.com>)
List pgsql-hackers


On Sat, Feb 29, 2020 at 2:38 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
On 2020-Feb-28, ahsan hadi wrote:


> Tested the pg_dump patch for dumping "ALTER .. DEPENDS ON EXTENSION" in case of indexes, functions, triggers etc. The "ALTER .. DEPENDS ON EXTENSION" is included in the dump. However in some case not sure why "ALTER INDEX.....DEPENDS ON EXTENSION" is repeated several times in the dump?

Hi, thanks for testing.

Are the repeated commands for the same index, same extension?

Yes same index and same extension...
 
  Did you
apply the same command multiple times before running pg_dump?

Yes but in some cases I applied the command once and it appeared multiple times in the dump..
 

There was an off-list complaint that if you repeat the ALTER .. DEPENDS
for the same object on the same extension, then the same dependency is
registered multiple times.  (You can search pg_depend for "deptype = 'x'"
to see that).  I suppose that would lead to the line being output
multiple times by pg_dump, also.  Is that what you did?

I checked out pg_depend for "deptype='x'" the same dependency is registered multiple times... 

If so: Patch 0002 is supposed to fix that problem, by raising an error
if the dependency is already registered ... though it occurs to me now
that it would be more in line with custom to make the command a silent
no-op.  In fact, doing that would cause old dumps (generated with
databases containing duplicated entries) to correctly restore a single
entry, without error.  Therefore my inclination now is to change 0002
that way and push and backpatch it ahead of 0001.

Makes sense, will also try our Patch 0002. 

I realize just now that I have failed to verify what happens with
partitioned indexes.

Yes I also missed this one..
 

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


--
Highgo Software (Canada/China/Pakistan)
URL : http://www.highgo.ca
ADDR: 10318 WHALLEY BLVD, Surrey, BC
EMAIL: mailto: ahsan.hadi@highgo.ca

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #16108: Colorization to the output of command-line hasunproperly behaviors at Windows platform
Next
From: Etsuro Fujita
Date:
Subject: Re: [BUG?] postgres_fdw incorrectly updates remote table if it hasinherited children.