Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5n92-0006Qv-O2 for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Sep 2018 07:25:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g5n90-0005vw-FL for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Sep 2018 07:24:58 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5n90-0005vp-59 for pgsql-hackers@lists.postgresql.org; Fri, 28 Sep 2018 07:24:58 +0000 Received: from feynman.df7cb.de ([195.49.152.168]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5n8w-0006w5-Q8 for pgsql-hackers@postgresql.org; Fri, 28 Sep 2018 07:24:57 +0000 Received: from msg.df7cb.de (unknown [IPv6:2003:5b:203b:100:7627:eaff:fe52:8e03]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by feynman.df7cb.de (Postfix) with ESMTPSA id 42M38z5p6Jz3Dyt; Fri, 28 Sep 2018 09:24:51 +0200 (CEST) Date: Fri, 28 Sep 2018 09:24:50 +0200 From: Christoph Berg To: Thomas Munro Cc: Peter Eisentraut , Pg Hackers Subject: Re: Collation versioning Message-ID: <20180928072450.GA26142@msg.df7cb.de> Mail-Followup-To: Christoph Berg , Thomas Munro , Peter Eisentraut , Pg Hackers References: <20180912081547.GA24584@msg.df7cb.de> <0447ec7b-cdb6-7252-7943-88a4664e7bb7@2ndquadrant.com> <20180912112548.GC24584@msg.df7cb.de> <4f60612c-a7b5-092d-1532-21ff7a106bd5@2ndquadrant.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Re: Thomas Munro 2018-09-27 > > > 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