From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Adrian von Bidder <avbidder(at)fortytwo(dot)ch> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: IMMUTABLE columns in tables? |
Date: | 2010-06-15 16:56:46 |
Message-ID: | 4C17B0CE.5020103@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 15/06/2010 2:41 AM, Adrian von Bidder wrote:
> Heyho!
>
> (Ok, seems to be feature wish day ...)
>
> I was wondering if others would find an IMMUTABLE (or whatever) column
> constraint useful as well. Semantics would (obviously?) be to disallow
> changing the value of this column after insert.
>
> I realize that this is possible via triggers, and with the recent
> possibility of having triggers fire only on changes to certain columns it's
> even (presumably) not much runtime overhead, but creating triggers is very
> verbose and doesn't make the db schema very readable.
Where possible, I do this with column priveleges, ensuring that nobody
(except the superuser) has UPDATE rights for that column. It's short and
simple, though it's only effective if the regular user isn't the same as
the table owner.
It'd be nice to have something stronger in the form of a column
qualifier (akin to NOT NULL), though, and much easier to show to be
correct. Column privs may be bypassed by a superuser (or a suitably
privileged SECURITY DEFINER function/trigger), and triggers can have
"interesting" interactions between them that make it hard to feel
confident in the effect.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Brad Nicholson | 2010-06-15 17:02:58 | pgcrypto in separate schema |
Previous Message | Alan Hodgson | 2010-06-15 16:42:45 | Re: Disk performance |