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
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 |