Comments on: Building SQL Strings Dynamically, in 2011

By: xocolatl

xocolatl — Mon, 11 Jul 2011 18:52:50 +0000

appreciated

By: Jeff Davis

Jeff Davis — Mon, 11 Jul 2011 15:47:06 +0000

Yes, I agree that you should be able to control plan caching. I was just offering a possible workaround.

By: xocolatl

xocolatl — Mon, 11 Jul 2011 12:39:24 +0000

There are two problems with that: it clutters the syntax (even though dollar quoting helps), and it doesn’t work at all in pure sql functions.

By: Jeff Davis

Jeff Davis — Sun, 10 Jul 2011 15:47:12 +0000

If you use EXECUTE rather than PERFORM, it won’t save the plan.

However, I agree that saving the plan should be more explicit.

By: xocolatl

xocolatl — Sun, 10 Jul 2011 12:21:50 +0000

The problem I run into with this construct is with functions because they store their plans without me asking. I wish there were a way to say “re-parse this function every time it’s called”.

By: Robert Young

Robert Young — Sat, 09 Jul 2011 19:09:26 +0000

– (I say “deceptive” here because it often just moves an even greater complexity into the application — but that’s another topic).

Well, it’s the main topic!! Coders want an infinite employment plan, and this is their main weapon.

So far as statement caching/saving/fooing is concerned, each engine does this its own way. Some save the entire query, parameters and all, and only reuse when a subsequent is an exact match. Others save the text, with “slots” for the parameters, and reuse if the text(s) match.

BTW, prepared statements are not a function of the engine, but the engine side of jdbc (or equivalent) driver. Prepared statement reuse is a separate issue from the engine’s reuse of statements. In engines with which I am familiar (PG being the least familiar), prepared statements are attached to the session/connection.

“Prepared statements only last for the duration of the current database session”
http://www.postgresql.org/docs/9.0/static/sql-prepare.html