Re: calling currval() before nextval() patch adding - Mailing list pgsql-patches

From John Hansen
Subject Re: calling currval() before nextval() patch adding
Date
Msg-id 1099873567.16869.54.camel@localhost.localdomain
Whole thread Raw
In response to Re: calling currval() before nextval() patch adding currval_isset()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: calling currval() before nextval() patch adding  (John Hansen <john@geeknet.com.au>)
List pgsql-patches
> I would argue that a program written that way is broken by definition,
> and we should not encourage programmers to write broken applications.

Hmmm,.... is mysql's last_insert_id behaviour really that much to ask
for?

This is basically what I'm trying to emulate, to make porting mysql
applications easier. That is, to ADD postgresql support to applications,
that have backend specific code abstracted.... Many such applications
use this particular method of getting the id. the function doing the
insert only knows the tablename (by parsing the query string).

Agreed those applications should probably be completely rewritten, but
for many, including myself, that would be an effort that goes in to the
too hard basket, and thus will never see support for postgresql. Which
in my opinion is a shame.

Should there maybe instead be a .conf option that allows you to supress
the warning message given by a call to currval() before nextval() ?

currval_no_warning = true ?

... John



pgsql-patches by date:

Previous
From: John Hansen
Date:
Subject: Re: calling currval() before nextval() patch adding
Next
From: John Hansen
Date:
Subject: Re: calling currval() before nextval() patch adding