From: | David Christensen <david(at)endpoint(dot)com> |
---|---|
To: | Pierre C <lists(at)peufeu(dot)com> |
Cc: | "Dimitri Fontaine" <dfontaine(at)hi-media(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Avoiding bad prepared-statement plans. |
Date: | 2010-02-19 02:31:05 |
Message-ID: | B2AD690B-D9B4-4D42-94AD-9D11CAE5DD03@endpoint.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Feb 18, 2010, at 2:19 PM, Pierre C wrote:
>
>> 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.
>
> Yep, but it's a bit awkward and time-consuming, and not quite suited
> to ORM-generated requests since you got to generate all the plan
> names, when the SQL query itself would be the most convenient
> "unique identifier"...
>
> A cool hack would be something like that :
>
> pg_execute( "SELECT ...", arguments... )
>
> By inserting a hook which calls a user-specified function on non-
> existing plan instead of raising an error, this could work.
> However, this wouldn't work as-is since the plan name must be <=
> NAMEDATALEN, but you get the idea ;)
How about the SHA1 hash of the query? Hey, it works for git... :-)
Regards,
David
--
David Christensen
End Point Corporation
david(at)endpoint(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2010-02-19 02:40:30 | Re: PGXS: REGRESS_OPTS=--load-language=plpgsql |
Previous Message | Euler Taveira de Oliveira | 2010-02-19 02:26:29 | Re: PGXS: REGRESS_OPTS=--load-language=plpgsql |