pg.ddx.io  pgsql-interfaces@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Andreas Theofilu <theofilu@eunet.at>
To: pgsql-interfaces@postgreSQL.org
Cc: theofilu@eunet.at
Subject: RE: [INTERFACES] ecpg and getting just assigned serial number
Date: Mon, 13 Sep 1999 15:46:51 +0200
Message-ID: <99091316123503.01664@theofilu> (raw)
References: <1BF7C7482189D211B03F00805F8527F748C06B@S-NATH-EXCH2>

Am Mo, 13 Sep 1999 schrieben Sie:
> It's would be pretty difficult to return the unique key, because that is
> defined by the user, and what if I had a table into which were placed values
> from two separate sequences (not great design, but possible), or a compound
> unique key, or multiple unique keys?  The things that's necessary here is
> for the sqlca struct to contain the oid of the newly inserted row after the
> insertion.  Of course, then there is a problem if more than one row is
> inserted.  What does Informix do then?

Agree. It's difficult to do that with PostgreSQL. It works with Informix
only because the type 'serial' is realy a seperate type and handled
completely different. Beside this it's allowed to have only one field of
type serial in a table. With SQL command 'insert' you can only insert one
sentence at a time. To enter more than one sentence you must program a
loop. So I can see no problem with the serial number. Beside this: The
serial field of Informix is independant of any index. Therefore it doesn't
matter how complicate an index may be.

> But why can't you just write a database function that performs the insert,
> and returns the value, and then call the function using embedded sql.  The
> function can be written in plsql, and accept as parameters all the values
> that need to go into the new record.  This is far better db design.

I can write such a function, of course. But I will not break compatibility
to Informix, because both databases, PostgreSQL _and_ Informix are
supported in only a single source file.

> The basic function looks like this (pseudocode):
> 
> BEGIN
> 	get next sequence value into i;
> 	insert new record using parameters and i;
> 	if insert fails then
> 		return (0);
> 	else
> 		return (i);
> END
> 
> This has the added benefit of being able to add further business rules into
> the function, which better encapsulates your process.  Of course, this is
> design dependent, but it's a method I've used quite successfully in the past
> (although, admittedly, not in PG ;-)

I've done exactly the same your example shows, but not in a seperate
function. I simply added one SQL command to get the next number out of the
sequence. This works well now and the extra line is ignored when compiling
for Informix :-).
--
Theofilu Andreas
http://members.eunet.at/theofilu

               -------------------------------------------------
                           Enjoy the science of Linux!
                       Genieße die Wissenschaft von Linux!
               -------------------------------------------------



view thread (13+ messages)  latest in thread

Message-ID: <99091316123503.01664@theofilu>
Permalink:  ../99091316123503.01664@theofilu/
Also on:    postgresql.org/message-id/99091316123503.01664@theofilu

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-interfaces@postgresql.org
  Cc: theofilu@eunet.at
  Subject: RE: [INTERFACES] ecpg and getting just assigned serial number
  In-Reply-To: <99091316123503.01664@theofilu>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox