From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | "Pierre C" <lists(at)peufeu(dot)com> |
Cc: | "Greg Stark" <gsstark(at)mit(dot)edu>, "Jeroen Vermeulen" <jtv(at)xs4all(dot)nl>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Bart Samwel" <bart(at)samwel(dot)tk>, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Avoiding bad prepared-statement plans. |
Date: | 2010-02-18 16:54:31 |
Message-ID: | 873a0ypjqw.fsf@hi-media-techno.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Pierre C" <lists(at)peufeu(dot)com> writes:
> On Thu, 18 Feb 2010 16:09:42 +0100, Dimitri Fontaine
> <dfontaine(at)hi-media(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-02-18 17:16:57 | Re: [COMMITTERS] pgsql: Introduce WAL records to log reuse of btree pages, allowing |
Previous Message | Pierre C | 2010-02-18 16:47:01 | Re: Avoiding bad prepared-statement plans. |