| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
| Cc: | Dominic Jones <jonesd(at)xmission(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: 10.4 upgrade, function markings, and template0 |
| Date: | 2018-05-14 21:22:39 |
| Message-ID: | 6047.1526332959@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> writes:
> On 05/14/2018 02:02 PM, Tom Lane wrote:
>> I didn't bother with spelling it all out in full detail this time,
>> which maybe was a mistake, but I felt that probably most users
>> wouldn't need to bother with these changes at all (unlike the case
>> where a catalog correction is security-related).
> Well what is nice about the news release is you can cut and past the
> entire list of commands and do the updates en masse.
It'd be nice to have some more-automated way of doing this type of
correction. Ordinary scripting doesn't look very promising, because
I don't see an easy way to deal with the need to connect to every
database in the cluster; that seems to depend on a lot of local
characteristics about usernames and authentication.
Maybe it'd be worth building some sort of infrastructure that would
allow this to be done at a lower level. It's not hard to imagine
an autovacuum-like or bgworker-based thingy that could run around
and apply a given SQL script in every database, bypassing the usual
worries about authentication and connections-disabled databases.
That seems like a lot of work for a need that only comes up once in
awhile, but perhaps it'd have more applications than just catalog
corrections.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2018-05-14 21:30:40 | Re: 10.4 upgrade, function markings, and template0 |
| Previous Message | Adrian Klaver | 2018-05-14 21:10:25 | Re: 10.4 upgrade, function markings, and template0 |