Re: Avoiding bad prepared-statement plans.

"Pierre C" <lists(at)peufeu(dot)com> writes:
> 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"...

The SHA1 proposal seems better to me.

Now you still have to fill the table with statements and names, and I
stand on the opinion that having a development-only layer in the ORM to
do just that is better.

That's supposing you don't generate so many different normalized queries
that you can't generate them all in dev or from the unit tests…

> 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.

This I'm not helping with. It's definitely not the same skills and time
requirements as offering a simple function based alternative to the
table lookup in preprepare, in the "load them all" phase.

> However, this wouldn't work as-is since the plan name must be <=
> NAMEDATALEN, but you get the idea ;)

SHA1 or even MD5 would do, the later having the advantage of being
already supported by PostgreSQL core.

Regards,
--
dim