From: | "Eric Ridge" <ebr(at)tcdi(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: pg_dump and DEFAULT column values |
Date: | 2001-11-07 22:55:53 |
Message-ID: | D3ADE25911614840BC69C72E3171E4ED028131@tcdiexch.tcdi.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> 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.
> The circular reference problem arises because SQL-language functions
> are parsed and checked at CREATE FUNCTION time. A cheezy way to get
> around it is to define the function before the table, but write it in
> a PL language --- presently, at least, PL function definitions are not
> checked until first use. So you could do
I ended up creating a "before on insert" trigger in plpgsql. pg_dump
seems to like this, and it gives me the ability to easily change how I
find the default value for this field.
And thanks for your time. It is very much appreciated.
eric
From | Date | Subject | |
---|---|---|---|
Next Message | Francisco Reyes | 2001-11-07 22:56:27 | Re: My new job with SRA |
Previous Message | Richard Teviotdale | 2001-11-07 22:50:15 | OID's as Primary Keys |