Re: Collation versioning - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: Collation versioning
Date
Msg-id 20180928072450.GA26142@msg.df7cb.de
Whole thread Raw
In response to Re: Collation versioning  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
Re: Thomas Munro 2018-09-27 <CAEepm=0EVCF_Nj5uYV5f6xH34MK1Z4mCfb+Svn1yJ_zsx5tOFw@mail.gmail.com>
> > > 4.  After creating a new database, update that row as appropriate in
> > > the new database (!).  Or find some other way to write a new table out
> > > and switch it around, or something like that.
> >
> > I've been hatching this exact scheme since the very beginning, even
> > thinking about using the background session functionality to do this.
> > It would solve a lot of problems, but there is the question of exactly
> > how to do that "(!)" part.

Making (!) work would also allow reassigning the "public" schema to
the database owner. That would fix that gross security gap that is
left with the default search_path, while still keeping usability. It
would make a whole lot of sense to work on making this feasible.

Christoph


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: heap_sync seems rather oblivious to partitioned tables (wal_level=minimal)
Next
From: Haribabu Kommi
Date:
Subject: Re: Libpq support to connect to standby server as priority