From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dmitriy Igrishin <dmitigr(at)gmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Bug or feature? (The constraint of the domain of extension can be dropped...) |
Date: | 2013-04-05 16:52:15 |
Message-ID: | 7705.1365180735@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Dmitriy Igrishin <dmitigr(at)gmail(dot)com> writes:
> 2013/4/5 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Clemens Eisserer | 2013-04-05 19:59:10 | BEFORE UPDATE trigger doesn't change column value |
Previous Message | Leonardo Carneiro | 2013-04-05 16:37:47 | Re: upgrading from V8.3.4 to V9.2.4 |