Re: Avoiding bad prepared-statement plans.
Dimitri Fontaine <dfontaine@hi-media.com>
From: Dimitri Fontaine <dfontaine@hi-media.com>
To: "Pierre C" <lists@peufeu.com>
Cc: "Greg Stark" <gsstark@mit.edu>, "Jeroen Vermeulen" <jtv@xs4all.nl>, "Tom Lane" <tgl@sss.pgh.pa.us>, "Robert Haas" <robertmhaas@gmail.com>, "Bart Samwel" <bart@samwel.tk>, "Pavel Stehule" <pavel.stehule@gmail.com>, pgsql-hackers@postgresql.org
Date: 2010-02-18T16:54:31Z
Lists: pgsql-hackers
"Pierre C" <lists@peufeu.com> writes: > On Thu, 18 Feb 2010 16:09:42 +0100, Dimitri Fontaine > <dfontaine@hi-media.com> wrote: >> http://preprepare.projects.postgresql.org/README.html >> http://packages.debian.org/source/sid/preprepare > > Hey, this thing is nice. Thanks :) > How hard would it be to put a hook in pg so that, instead of raising an > error and cancelling the txn when EXECUTing a statement that is not > prepared, it would call a user function (of the user's choice) which would, > if possible, prepare said statement, or if not, raise the error ? What about catching the error in the application and INSERT'ing into the current preprepare.relation table? The aim would be to do that in dev or in pre-prod environments, then copy the table content in production. Notice you can also SET preprepare.relation TO 'any.table_or_view', so that you can have more than one table for different applications or parts. I wonder how far you'd get using a VIEW instead and calling a user function there, but arranging preprepare to support a function instead is indeed possible. I'll try and see about it this evening, maybe tomorrow afternoon. Regards, -- dim