"Pierre C" <li...@peufeu.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers