Thread: Bug or feature? (The constraint of the domain of extension can be dropped...)
Bug or feature? (The constraint of the domain of extension can be dropped...)
From
Dmitriy Igrishin
Date:
Hey hackers,
--
// Dmitriy.
According to
"PostgreSQL will not let you drop an individual object contained in an extension, except by dropping the whole extension."
But this rule does not apply to domain constraints, i.e. it is not possible
to drop domain of some extenstion but it is possible to drop any or all of
its constraints. (And in fact drop it.)
I am consider this is a bug. Don't you?
// Dmitriy.
Re: Bug or feature? (The constraint of the domain of extension can be dropped...)
From
Tom Lane
Date:
Dmitriy Igrishin <dmitigr@gmail.com> writes: > According to > http://www.postgresql.org/docs/9.2/static/extend-extensions.html > "PostgreSQL will not let you drop an individual object contained in an > extension, except by dropping the whole extension." > But this rule does not apply to domain constraints, i.e. it is not possible > to drop domain of some extenstion but it is possible to drop any or all of > its constraints. (And in fact drop it.) > I am consider this is a bug. Don't you? No. The domain is a member of the extension, its properties are not. We do not generally forbid ALTER on extension members. During development for instance a quick ALTER can be a whole lot more convenient than dropping and reloading the whole extension. Whether it's a good idea to ALTER extension member objects in production is a different question. Typically you'd install them as owned by somebody with sense enough not to do that. regards, tom lane
Re: Bug or feature? (The constraint of the domain of extension can be dropped...)
From
Dmitriy Igrishin
Date:
2013/4/5 Tom Lane <tgl@sss.pgh.pa.us>
No. The domain is a member of the extension, its properties are not.Dmitriy Igrishin <dmitigr@gmail.com> writes:
> According to
> http://www.postgresql.org/docs/9.2/static/extend-extensions.html
> "PostgreSQL will not let you drop an individual object contained in an
> extension, except by dropping the whole extension."
> But this rule does not apply to domain constraints, i.e. it is not possible
> to drop domain of some extenstion but it is possible to drop any or all of
> its constraints. (And in fact drop it.)
> I am consider this is a bug. Don't you?
We do not generally forbid ALTER on extension members. During
development for instance a quick ALTER can be a whole lot more
convenient than dropping and reloading the whole extension.
Debatable, because in practice during development it's often better to recreate
the whole database which takes seconds. (The database with hundreds of
functions, views, domains, triggers etc.)
In fact, we store all except CREATE TABLE ... in files. In particular,
storing functions in file(s) are much much much more convenient
for big refactoings (which are often during development) rather than using
annoying \ef in psql(1) which just a time killer.
Whether it's a good idea to ALTER extension member objects in production
is a different question. Typically you'd install them as owned by
somebody with sense enough not to do that.
Indeed. To *me*, you solution looks like workaround. But of course,
this is debatable.
Well, thank you for explanation!
// Dmitriy.
Re: Bug or feature? (The constraint of the domain of extension can be dropped...)
From
Tom Lane
Date:
Dmitriy Igrishin <dmitigr@gmail.com> writes:
> 2013/4/5 Tom Lane <tgl@sss.pgh.pa.us>
>> We do not generally forbid ALTER on extension members. During
>> development for instance a quick ALTER can be a whole lot more
>> convenient than dropping and reloading the whole extension.
> Debatable, because in practice during development it's often better to
> recreate the whole database which takes seconds.
[ shrug... ] Maybe in *your* usage that's invariably true, but other
people do things differently. A typical case where it's important not
to force this is where you're working on a datatype extension, and
dropping the extension would require dropping all your tables containing
test data. If you're doing performance testing you've probably got
enough test data that a drop and reload will be costly.
Anyway, the established design is that the extension mechanism per se
is not meant to prevent altering an extension's member objects, only
dropping them altogether.
regards, tom lane