On Fri, Sep 29, 2017 at 2:06 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > My tendency about this patch is still that it should be rejected. This > is presenting additional handling for no real gain.
I vehemently disagree. If the server lets you create a tablespace, then everything that happens after that ought to work. On another thread, there is the issue that if you create a tablespace inside $PGDATA, things break. We should either unbreak those things or not allow creating the tablespace in the first place. On this thread, there is the issue that if you create two tablespaces for different PG versions in the same directory, things break. We should either unbreak those things or not allow creating the tablespace in the first place. It is completely awful behavior to let users do things and then punish them later for having done them. Users are not obliged to read the minds of the developers and guess what things the developers consider "reasonable". They should be able to count on the principle that if they do something that we consider wrong, they'll get an error when they try to do it -- not have it superficially appear to work and then explode later. To put that another way, there should be ONE rule about what is or is not allowable in a particular situation, and all commands, utilities, etc. that deal with that situation should handle it in a uniform fashion. Each .c file shouldn't get to make up its own notion of what is or is not supported. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers