Re: [HACKERS] getting new serial value of serial insert - Mailing list pgsql-hackers

From wieck@debis.com (Jan Wieck)
Subject Re: [HACKERS] getting new serial value of serial insert
Date
Msg-id m11jDPy-0003kLC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Re: [HACKERS] getting new serial value of serial insert  ("Aaron J. Seigo" <aaron@gtv.ca>)
List pgsql-hackers
>
> hi...
>
> >
> > No, and I'm not sure it'd be good to couple the two operations syntactically
> > even if one thought of a clever way to do it.  Serial-insert value retrieval is
> > a very frequent lightweight operation that fits nicely within current INSERT
> > syntax, and thus it seems intuitively "natural" to stretch INSERT semantics
> > in this way.
>
> put that way, i can see your point clearly and agree... =)
>
> i think this would be a nice addition to pgsql...
>
> > In the trigger scenario you mention, I'd be slightly more inclined to say it
> > crosses the fuzzy gray line into the area where a subsequent SELECT is in
> > order, as opposed to modifying INSERT syntax/semantics to allow this
> > SELECT functionality.  How's that for fuzzy logic?

    Don't  forget  about  a  BEFORE  ROW  trigger that decides to
    return a NULL tuple  instead  of  a  valid  (maybe  modified)
    tuple.  Thus,  it  suppresses  the  entire  INSERT, UPDATE or
    DELETE operation silently. You cannot access  a  plain  value
    then  without  having a flag telling that there is a value at
    all.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] PostgreSQL 6.5.3 built, but not released ...
Next
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] PostgreSQL 6.5.3 built, but not released ...