Re^2: Quick DBI do question

As well, in place of a single do statement, it's probably a good idea to parse it out into a prepare and execute set, possibly with prepare statements...

I thought the point of do was to avoid having to explicitly prepare and execute a statement handle. If you're performing an action where there are no rows returned, there is no need for that.

Comment on Re^2: Quick DBI do question Download Code

Replies are listed 'Best First'.
Re^3: Quick DBI do question by kennethk (Abbot) on Feb 13, 2009 at 16:21 UTC
It is, but given the nature of the question, it's reasonable to think that the OP hasn't considered which is correct for [his\|her] situation. But yes, I should have said "good idea to consider parsing it".	[reply]
Re^3: Quick DBI do question by doom (Deacon) on Feb 15, 2009 at 03:23 UTC
I thought the point of do was to avoid having to explicitly prepare and execute a statement handle. If you're performing an action where there are no rows returned, there is no need for that. The point of the prepare/execute idiom is to give the database a chance to parse the SQL just once, and re-use some work it's done already. This is often a huge efficiency gain, though obviously, only in the case where you're going to be running the SQL statement multiple times. Myself, I always do a prepare and execute out of habit... it's an extra line of code, but it makes refactoring it easier if the needs change. (By the way, if you do need to do a lot of multi-row inserts, you should consider avoiding the INSERT statement at all, and look into using a bulk-loader instead -- in Postgresql it's COPY.)	[reply]