On Thu, Jan 18, 2018 at 6:35 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > If we did it like that, the rationale for an actual --set-db-properties > switch would vanish, at least so far as pg_dumpall is concerned -- we > could just make all that behavior an integral part of --create. And > this wouldn't need to be conditional on getting ALTER DATABASE > CURRENT_DATABASE done.
Unfortunately, I have a feeling that --set-db-properties might not be the only thing that would vanish. I think users are accustomed by now to the idea that if you restore into an existing database, the existing contents are preserved and the new stuff from the dump is added (possibly with some errors and messiness). With this design, the existing database contents will instead vanish, and that is probably going to make somebody unhappy. I agree with you that making ALTER DATABASE accept CURRENT_DATABASE is a good idea. I don't have a great idea what to do about the SET TABLESPACE problem. It's always seemed to me to be sort of weird that you have to have a database in order to create, drop, etc. another database, or even get a list of databases that exist. As a new user, I remember being quite frustrated that connecting to a database that didn't exist gave no hint of how to find out what databases did exist. Eventually I discovered psql -l and all was well, but I had no idea how it worked under the hood. Even though I now understand the architectural considerations that have gotten us to where we are, I still think it would be more intuitive to users if there were a command-shell unrelated to any database that would let you perform operations on databases. I realize, however, that this patch isn't going to create such a thing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
