Robert Haas <robertmh...@gmail.com> writes:
> Well, sorta. To be honest, I think this patch is really ugly. If we
> were going to do this then, yes, I would want to split the patch into
> two parts along those lines. But actually I don't really want to do
> it this way at all. It's not that I don't want the performance
> benefits: I do. But the current code is really easy to read and
> extremely simple, and this changes it into something that is a heck of
> a lot harder to read and understand. I'm not sure exactly what to do
> about that, but it seems like a problem.
I haven't read the patch in any detail, but keep in mind that part of the
API contract for ResourceOwners is that ResourceOwnerRememberFoo() cannot
fail. Period. So any patch that makes those functions less than trivial
is going to be really suspect from a reliability standpoint. It would be
advisable for example that hash_any not suddenly become covered by the
"must not fail" requirement.
BTW, I do not think you can get away with the requirement that all-zeroes
isn't a valid resource representation. It might be okay today but it's
hardly future-proof.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
