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

From Pierre C
Subject Re: Avoiding bad prepared-statement plans.
Date
Msg-id op.u8caiphxeorkce@localhost
Whole thread Raw
In response to Re: Avoiding bad prepared-statement plans.  (Dimitri Fontaine <dfontaine@hi-media.com>)
Responses Re: Avoiding bad prepared-statement plans.
Re: Avoiding bad prepared-statement plans.
List pgsql-hackers
> 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 ;)


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: A thought: should we run pgindent now?
Next
From: "Greg Sabino Mullane"
Date:
Subject: Re: Listen/Notify payload and interfaces