Re: Nextval Problems - Mailing list pgsql-php

Hi Keary,

Thanks for the insight, and thanks for the offer. I could send the page over
to you, but I think that it may not be necessary. I split the queries up
separately, and used the currval to get the inserted id after it had been
done. Everything seems to be working great, and I'll be removing all the
unnecessary ";"s :)

I'd love to have you look over the code, as I'm definitely in need of some
fine tuning, but as you say, you don't have all day to sit around looking at
list members' code, so unless you'd like to specifically, I'll just say
thanks for the help, and leave it at that.

Tom

-----Original Message-----
From: pgsql-php-owner@postgresql.org
[mailto:pgsql-php-owner@postgresql.org]On Behalf Of Keary Suska
Sent: Thursday, August 22, 2002 10:25 AM
To: Postgres-PHP
Subject: Re: [PHP] Nextval Problems


on 8/22/02 10:14 AM, tom@betterhealthfoundation.org purportedly said:

> Why is "building it all the insertion pieces into one query separated by
> ";", of course" a bad idea?

If for no other reason, it makes code difficult to debug and manage. For
instance, in the case of a failure, there is no way to know which statement
failed unless there is enough context in the error message (which there
wouldn't be if the queries are similar in structure, like a series of INSERT
statements on a single table). Also, unless code is very carefully
maintained you can open security holes. You also have no control over
exception handling, unless every time you do something it is an
all-or-nothing event (i.e., using transactions, rollback is issued upon
*any* exception). Again, it requires more planning and maintenance to
support multiple query calls than to simply issue them singly.

> Could you explain why "The semicolon in the query is at least superfluous
if
> not dangerous." - sorry, it's just I thought that was a standard way to
> close out a SQL query, and I wonder if you could set me straight there.
And
> I am definitely not calling setval anywhere else in the code, unless it is
> called implicitly by an "INSERT" query.

It is superfluous to the extent that the pg_exec/pg_query commend
automatically issues a "go" instruction (what tells the backend to execute
the query). So what you are doing is the same as doing the following in the
psql shell:
    SELECT * FROM table;;
                       ^^ note double semicolons
So you are actually executing two statements--the select, and then a null
statement. Postgres ignores the null statement, which makes it seem like it
works. But an unexpected bug could cause statements to be executed that you
don't want to, as well as open a security hole.

Again, you have more control.

> If it would be helpful and you are interested in spending the time to look
> over it, I could send you the file in full to review - I'm relatively new
to
> php-postgres, and would definitely appreciate another set of eyes - this
> applies to anyone else as well.

You can send it to me personally, if you do not wish the code to be public.
I will take a look, but I can't promise anything ;-) HOWEVER, before you do
that, break out all your queries into individual calls. Otherwise it makes
debugging difficult, and hence harder for me to help, which usually amounts
to not getting the kind of help you need, since, after all, we all have more
important things to do that debug list member's code all day ;-)

Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org