Re: pg_dump and DEFAULT column values

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Eric Ridge" <ebr(at)tcdi(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_dump and DEFAULT column values
Date: 2001-11-07 23:50:13
Message-ID: 7887.1005177013@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Eric Ridge" <ebr(at)tcdi(dot)com> writes:
>> Hmm. I think you should think hard about why you believe that the
>> default has to work that way and you can't just use a sequence.
>> You're paying a high price to conform to what seems a very
>> questionable set of assumptions.

> I use the field for sorting, and since the client application has the
> ability to change the value of this field, it is possible they could set
> it to a number larger than the next value of the sequence. then an
> insert of a new record would appear before the changed record, instead
> of after it.

But if you allow applications to change the field, then all bets about
sort order are off anyway, no? It's far from clear exactly what
semantics you think you are guaranteeing here.

In any case it seems like changing the initially-assigned field value
is an infrequent operation, and that you ought to make *that* be the
expensive and not-safe-for-parallelism case, not row insertion.
(Perhaps this is a wrong assumption on my part, in which case ignore
what follows.) I'd still be inclined to use a sequence for insertion,
and to enforce consistency on update with an AFTER UPDATE trigger that
does something like
if old.fld != new.fld then
begin
lock mytable;
select setval('seq', max(fld)) from table;
end;
(Untested, but I hope the idea is clear.)

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jason Earl 2001-11-07 23:55:14 Re: performance tuning
Previous Message Marc G. Fournier 2001-11-07 23:43:06 PostgreSQL v7.2b2 Released