Re: Parsing of aggregate ORDER BY clauses

2010/7/19 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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