Обсуждение: Is it safe to use DEFAULT currval()

I've got a table, and I'm trying to track changes to it, but can't do it via a
primary key including a revision-number (historical reasons).

CREATE TABLE foo (
  id       SERIAL,
  blah     text,
  tracking int4 DEFAULT currval('foo_id_seq')
  PRIMARY KEY (id)
);

I'm actually setting the DEFAULT on tracking using ALTER TABLE after the
event.

Now - it works, but is that a design feature or just luck?

It's convenient that tracking = id of the first entry, but not vital, so I can
always use a separate sequence if needs be.

--
  Richard Huxton
  Archonet Ltd

Richard Huxton <dev@archonet.com> writes:
> CREATE TABLE foo (
>   id       SERIAL,
>   blah     text,
>   tracking int4 DEFAULT currval('foo_id_seq')
>   PRIMARY KEY (id)
> );

> Now - it works, but is that a design feature or just luck?

You're essentially assuming that the column expressions for an INSERT
will be evaluated left-to-right.  That's true at the moment, and I don't
see any foreseeable reason why we'd change it, but it surely is an
implementation dependency that could bite you someday.

            regards, tom lane

On Saturday 27 September 2003 18:40, Tom Lane wrote:
> Richard Huxton <dev@archonet.com> writes:
> > CREATE TABLE foo (
> >   id       SERIAL,
> >   blah     text,
> >   tracking int4 DEFAULT currval('foo_id_seq')
> >   PRIMARY KEY (id)
> > );
> >
> > Now - it works, but is that a design feature or just luck?
>
> You're essentially assuming that the column expressions for an INSERT
> will be evaluated left-to-right.  That's true at the moment, and I don't
> see any foreseeable reason why we'd change it, but it surely is an
> implementation dependency that could bite you someday.

I feared as much. Ah well, use nextval(), a different sequence or write a
trigger I suppose.

--
  Richard Huxton
  Archonet Ltd