Re: calling currval() before nextval() patch adding

From: John Hansen <john(at)geeknet(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: calling currval() before nextval() patch adding
Date: 2004-11-08 00:26:07
Message-ID: 1099873567.16869.54.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message John Hansen 2004-11-08 01:49:08 Re: calling currval() before nextval() patch adding
Previous Message John Hansen 2004-11-08 00:10:23 Re: calling currval() before nextval() patch adding