Am Dienstag, den 25.01.2005, 08:36 -0500 schrieb Alex Turner:
> Actualy max() works just fine. It's not the solution I use in the
> middle tier, but it works for a functional example. both max() and
> currval() are bad because they can cause a race condition where the
> sequence has been incremen
On Tue, Jan 25, 2005 at 08:36:53AM -0500, Alex Turner wrote:
> Actualy max() works just fine. It's not the solution I use in the
> middle tier, but it works for a functional example. both max() and
> currval() are bad because they can cause a race condition where the
> sequence has been increment
On Mon, 24 Jan 2005, Alex Turner wrote:
> Insert fails with a foreign key constraint error because entity_phone
> points to entity, not person, and the rows aren't physicaly in entity,
> they are in person.
>
> Two questions:
> 1) Why can't we make this work the 'right' way - not doing so either
>
Actualy max() works just fine. It's not the solution I use in the
middle tier, but it works for a functional example. both max() and
currval() are bad because they can cause a race condition where the
sequence has been incremented by another thread. It's always better
to get nextval('sequence')
On Mon, Jan 24, 2005 at 07:22:32PM -0500, Alex Turner wrote:
> I am facing the classic pgsql ORDBMS problem:
Why are you using MAX()? That won't work at all. Perhaps you need to
look up the documentation for nextval and currval. In particular, that
second query should be:
insert into entity_pho
