Re: Avoiding bad prepared-statement plans. - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Avoiding bad prepared-statement plans.
Date
Msg-id 873a0ypjqw.fsf@hi-media-techno.com
Whole thread Raw
In response to Re: Avoiding bad prepared-statement plans.  ("Pierre C" <lists@peufeu.com>)
Responses Re: Avoiding bad prepared-statement plans.
List 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


pgsql-hackers by date:

Previous
From: "Pierre C"
Date:
Subject: Re: Avoiding bad prepared-statement plans.
Next
From: Simon Riggs
Date:
Subject: Re: [COMMITTERS] pgsql: Introduce WAL records to log reuse of btree pages, allowing