Re: Re: postgres TODO

From: Ed Loehr <eloehr(at)austin(dot)rr(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alessio Bragadini <alessio(at)albourne(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: postgres TODO
Date: 2000-07-10 15:35:50
Message-ID: 3969ED56.8CD45D14@austin.rr.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
> Alessio Bragadini <alessio(at)albourne(dot)com> writes:
> > Peter Eisentraut wrote:
> >>>> * Add function to return primary key value on INSERT
> >>
> >> I don't get the point of this. Don't you know what you inserted? For
> >> sequences there's curval()
>
> To get back to Peter's original question, you don't necessarily "know
> what you inserted" if you allow columns to be filled with default values
> that are calculated by complicated functions. A serial column is just
> the simplest example of that. Whether this situation is common enough
> to justify a special hack in INSERT is another question. I kinda doubt
> it. We already return the OID which is sufficient info to select the
> row again if you need it. Returning the primary key would be
> considerably more work for no visible gain in functionality...

It's definitely not a crucial functionality gain, IMO, but it is
nonetheless a gain when you consider that *every* pgsql developer on
the planet could then do something in one query that currently takes
two (plus the requisite error-handling code). A few other counter-
arguments for returning the autoincrement/serial/pkey:

1) it earns bad press w/r/t usability;
2) it is an FAQ on the lists;
3) it is an extremely common operation;
4) other DBs provide it;

Regards,
Ed Loehr

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2000-07-10 15:39:54 Re: Re: [GENERAL] PostgreSQL vs. MySQL
Previous Message Tom Lane 2000-07-10 15:28:48 Re: memory: bug or feature