Re: Remove superuser() checks from pgstattuple - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Remove superuser() checks from pgstattuple
Date
Msg-id 6659.1473004506@sss.pgh.pa.us
Whole thread Raw
In response to Re: Remove superuser() checks from pgstattuple  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Remove superuser() checks from pgstattuple
Re: Remove superuser() checks from pgstattuple
List pgsql-hackers
[ warning, thread hijack ahead ]

Stephen Frost <sfrost@snowman.net> writes:
> * Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
>> I think this is a good change to pursue, and we'll likely want to do
>> more similar changes in contrib.  But I'm worried that what is logically
>> a 10-line change will end up a 20 KiB patch every time.

> We also created a new version to add the PARALLEL SAFE markings to the
> functions.  In general, I believe it's better to use a new version when
> we're making these kinds of changes.

It is becoming clear that the current extension update mechanism is kind
of brute-force for this sort of change.  I have no ideas offhand about a
better way to do it, but like Peter, I was dismayed by the amount of pure
overhead involved in the PARALLEL SAFE updates.

It's not only development overhead, either: users have to remember to
run around and issue ALTER EXTENSION UPDATE for every extension they
have, in every database they have it installed in.  Anyone want to
lay a side bet on how many users will actually do that?  Given that
the release notes don't currently suggest doing so, I'd be willing
to put money on "none at all" :-(

I wonder whether pg_upgrade ought to be changed to attempt upgrading
every extension after it's completed the basic migration.  Or at
least offer a script containing all the needed commands.

Anyway, it's not this particular patch's job to do better, but we
oughta think about better ways to do it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Remove superuser() checks from pgstattuple
Next
From: Pavel Stehule
Date:
Subject: Re: Make better use of existing enums in plpgsql