2010/7/19 Tom Lane <tgl@sss.pgh.pa.us>:
> I looked into the problem reported here:
> http://archives.postgresql.org/pgsql-bugs/2010-07/msg00119.php
>
> 1. Postpone coercion of the function inputs till after processing of
> the ORDER BY/DISTINCT decoration. This isn't too good because then
> we'll be using the "wrong" data type for deciding the semantics of
> ORDER BY/DISTINCT. That could lead to bizarre behavior or even
> crashes, eg if we try to use numeric sort operators on a value that
> actually has been coerced to float8. We could possibly go back and
> re-do the decisions about data types but it'd be a mess.
>
> 2. Split the processing of aggregates with ORDER BY/DISTINCT so that the
> sorting/uniqueifying is done in a separate expression node that can work
> with the "native" types of the given columns, and only after that do we
> perform coercion to the aggregate function's input types. This would be
> logically the cleanest thing, perhaps, but it'd represent a very major
> rework of the patch, with really no hope of getting it done for 9.0.
>
> 3. Do something so that we can still match "t::text" to "t". This
> seems pretty awful on first glance but it's not actually that bad,
> because in the case we care about the cast will be marked as having
> been applied implicitly. Basically, instead of just equal() comparisons
> in findTargetlistEntrySQL99(), we'd strip off any implicit cast at the
> top of either expression, and only then do equal(). Since the implicit
> casts are, by definition, things the user didn't write, this would still
> have the expected behavior of matching expressions that were identical
> when the user wrote them.
>
> #3 seems the sanest fix, but I wonder if anyone has an objection or
> better idea.
I didn't look at the code yet, #2 sounds like the way to go. But I see
the breakage is unacceptable for 9.0, so #3 is the choice for 9.0 and
will we fix it as #2 for 9.1 or later?
Regards,
--
Hitoshi Harada