calling currval() before nextval() patch adding currval_isset()

Hi list,

attached, cvs context diff that adds currval_isset('sequence_name');

Updated patch attached, didn't think to update the docs. Thanks oicu!

Kind Regards,

John Hansen

On Sun, 2004-11-07 at 17:21, John Hansen wrote:

Hi list,

attached, cvs context diff that adds currval_isset('sequence_name');

With this patch, I can now call currval_isset to determine if I need to
call currval. Previously, I just called currval, but with the result of
filling up the server log with warnings.

This might do what you're looking for on 8.0.

CREATE OR REPLACE FUNCTION currval_isset(text) RETURNS bigint AS '
DECLARE
var integer;
BEGIN
SELECT currval($1) INTO var;

RETURN var;

EXCEPTION
WHEN OBJECT_NOT_IN_PREREQUISITE_STATE THEN
RETURN 0;
END;
' LANGUAGE plpgsql;

SELECT isset('tst_seq');

John Hansen <john@geeknet.com.au> writes:

attached, cvs context diff that adds currval_isset('sequence_name');

This avoids the warning messages you get when calling currval before
nextval in situations where the program flow does not allow you to
predetermine if the current session has called nexval yet.

I would argue that a program written that way is broken by definition,
and we should not encourage programmers to write broken applications.

regards, tom lane

This might do what you're looking for on 8.0.

CREATE OR REPLACE FUNCTION currval_isset(text) RETURNS bigint AS '
DECLARE
var integer;
BEGIN
SELECT currval($1) INTO var;

RETURN var;

EXCEPTION
WHEN OBJECT_NOT_IN_PREREQUISITE_STATE THEN
RETURN 0;
END;
' LANGUAGE plpgsql;

SELECT isset('tst_seq');

k, i don't actually have an 8.0 installation to play with here,. but
won't this still produce a warning?

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

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

Come to think of it,.... maybe the attached last_insert_id() patch is a
better option. Actually copying the behaviour of mysql's counterpart.

... John