>
> > I've run the regression tests on today's source tree, and found lots of
> > ordering differences..., and one different result.
> >
> > The different result is in the "select_distinct_on" test; the original
> > result had 8 rows and the new result has 40 rows. However, I'm getting
> > myself confused on what the correct result _should_ be, since "select
> > distinct on" is not documented. For a query like:
> >
> > SELECT DISTINCT ON string4 two, string4, ten FROM temp;
> >
> > What is the "ON string4 two" clause saying? Anyway, the result is
> > different than before, so we would probably want to look at it. I'm away
> > 'til after the weekend, but can help after that.
>
> Hi Bruce. Some of the "order by" clauses are currently broken in the
> regression tests (at least on my machine). Do you see this also? For
> example, in the point test:
>
> QUERY: SET geqo TO 'off';
> QUERY: SELECT '' AS thirtysix, p1.f1 AS point1, p2.f1 AS point2, p1.f1 <->
> p2.f1 AS dist
> FROM POINT_TBL p1, POINT_TBL p2
> ORDER BY dist, point1 using <<, point2 using <<;
> thirtysix|point1 |point2 | dist
> ---------+----------+----------+----------------
> |(0,0) |(-10,0) | 10
> |(-10,0) |(-10,0) | 0
> |(-3,4) |(-10,0) |8.06225774829855
> ...
>
> Also, some of Vadim's contrib stuff is broken since WARN is no longer
> defined. I can post patches for that (there are two files affected) but
> substituted ERROR and am not certain whether that is the correct choice.
>
> Let me know if I can help with anything...
I am starting to agree with Vadim that it is too much work to go though
every elog(), and doing it by directory or file is very imprecise, and
may cause confusion.
Should I throw in the towel and make them all ERROR?
I don't know anything that would cause the ORDER BY problems.
--
Bruce Momjian
maillist@candle.pha.pa.us