Greg Stark <gsst...@mit.edu> writes:
> On Wed, Apr 27, 2011 at 12:23 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Any ideas about better answers?
> Here's a crazy idea. We could use string equality of the out
> function's representation instead. If an output function doesn't
> consistently output the same data for things that are equal or
> different data for things that aren't equal then there's a bug in it
> already since it means the data type won't survive a pg_dump/reload.
Hmm, cute idea, but existing output functions don't actually cooperate
with this goal very well:
* float4_out, float8_out, and most geometry types don't promise to
produce invertible results unless extra_float_digits is set high enough.
* timestamptz_out and friends react to both DateStyle and TimeZone
settings, which means you lose in the other direction: identical values
could print differently at different times. This is a killer for the
planner's use since what it's doing is precisely comparing constants
generated during index or rule creation to those appearing in queries.
I think if we were going to go down this road, we'd have little choice
but to invent the specific concept of a type-specific "identity" function,
"foo_identical(foo, foo) returns bool". This wouldn't present any pain
for most datatype authors since omitting it would just license the
system to assume bitwise equality is the right behavior. As far as the
other issues I mentioned go:
* We could dodge most of the performance hit if Const carried a flag
indicating whether the datatype has an identity function or not. This
would allow equal() to fall through without a table lookup in the large
majority of cases. It wouldn't add any expense to Const construction
since you already have to know or fetch other datatype properties like
pass-by-value.
* We could likely finesse the transactional-safety issue by allowing
equal() to fall back on bitwise comparison if not IsTransactionState.
I'm still not sure whether there actually are any cases where it has
to work outside a transaction, and if there are, the dumb/conservative
behavior is probably adequate.
Still, it'd be a lot of work, and it doesn't offer any chance of a
back-patchable fix. Looking at Noah's valgrind results, I'm inclined
to just go seal off the known holes instead.
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
