Re: IMMUTABLE columns in tables?

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

In response to

Responses

Browse pgsql-general by date

  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