From: | Neil Dugan <postgres(at)butterflystitches(dot)com(dot)au> |
---|---|
To: | Postgresql-General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: table synonyms |
Date: | 2005-05-29 01:08:43 |
Message-ID: | 1117328923.4709.12.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, 2005-05-24 at 19:48 +0200, Tino Wildenhain wrote:
> Am Dienstag, den 24.05.2005, 13:49 -0300 schrieb jjeffman(at)cpovo(dot)net:
> > It will be a very pleasant idea. Although I am
> > an application developer I don't know if I have
> > enough knowledge to do that. Do you know how could
> > I help the PostgreSQL development ?
> >
> > Another feature I missed is the "returning" clause
> > of the Oracle "INSERT" SQL command, which allow the
> > user to retrieve the "serial" value after an insert
> > command, which works even in a concurrent network
> > environment.
>
> INSERT INTO table (...) values (...);
> SELECT currval('table_id_seq');
>
> See documentation for sequences.
>
At times when I have been using a serial number of one table as a link
for another. I have set the 'id' field to a type bigint then used the
code below
SELECT nexval('table_id_seq');
number = result;
INSERT INTO table (id,...) values (number,...);
Then used the value in 'number' for other queries. If two users do the
same query at the same time they both get different values and each wont
get confused as to who used what value.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Browne | 2005-05-29 03:37:34 | Re: Fast request for version checking.... |
Previous Message | Peter Eisentraut | 2005-05-28 20:15:54 | Re: Fast request for version checking.... |