| From: | Christoph Berg <myon(at)debian(dot)org> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Collation versioning |
| Date: | 2018-09-28 07:24:50 |
| Message-ID: | 20180928072450.GA26142@msg.df7cb.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Re: Thomas Munro 2018-09-27 <CAEepm=0EVCF_Nj5uYV5f6xH34MK1Z4mCfb+Svn1yJ_zsx5tOFw(at)mail(dot)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Haribabu Kommi | 2018-09-28 07:31:47 | Re: Libpq support to connect to standby server as priority |
| Previous Message | David Rowley | 2018-09-28 07:22:44 | Re: heap_sync seems rather oblivious to partitioned tables (wal_level=minimal) |