On Fri, Sep 29, 2017 at 2:06 AM, Michael Paquier
<michael.paquier@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