Re: consttraints.source

Hi,

I'm seeing similar problems, mainly due to failure to sort correctly
even though there is an "order by" clause.

I did a few tests and found that the sort sort seemed to fail when there
were multiple columns in the "order by" clause. (Not conclusive)

I don't know when it 1st appeared as I've been trying to compile on
SPARC-Linux for the past few attempts and this is the 1st time I've
had a fully working package to run the regression tests on!!

Thanks,
Keith.

Bruce Momjian <maillist@candle.pha.pa.us>

emkxp01@mtcc.demon.co.uk

Bruce,

Just running the regression tests on the latest CVS on SPARC-Linux!!

Appart from several other ordering and precision errors I'm seeing
errors in constraints tests due to output/constraints.source not
being updated for the new error messages.

I have just fixed many of these WARN problems. I am looking at the new
results. The first problem:

====== boolean ======
166,168d165
< |f |f
< |f |f
< |f |f
170a168

|f |f

173a172

|f |f

176a176

|f |f

is because the query has no ORDER BY.

The second problem looks serious:

QUERY: SET geqo TO 'off';
QUERY: SELECT '' AS thirtysix, p1.f1 AS point1, p2.f1 AS point2, p1.f1<->

p2.f$

Hi,

I'm seeing similar problems, mainly due to failure to sort correctly
even though there is an "order by" clause.

I did a few tests and found that the sort sort seemed to fail when there
were multiple columns in the "order by" clause. (Not conclusive)

This is a huge help. I think I have found it. I just overhauled the
readfunc/outfunc code, so it was now very clear that was in the
Query.sortClause.

Your hint that the it fails when there is more than one sort identifier
was the trick.

I don't know when it 1st appeared as I've been trying to compile on
SPARC-Linux for the past few attempts and this is the 1st time I've
had a fully working package to run the regression tests on!!

Thanks,
Keith.

Bruce Momjian <maillist@candle.pha.pa.us>

emkxp01@mtcc.demon.co.uk

Bruce,

Just running the regression tests on the latest CVS on SPARC-Linux!!

Appart from several other ordering and precision errors I'm seeing
errors in constraints tests due to output/constraints.source not
being updated for the new error messages.

I have just fixed many of these WARN problems. I am looking at the new
results. The first problem:

====== boolean ======
166,168d165
< |f |f
< |f |f
< |f |f
170a168

|f |f

173a172

|f |f

176a176

|f |f

is because the query has no ORDER BY.

The second problem looks serious:

QUERY: SET geqo TO 'off';
QUERY: SELECT '' AS thirtysix, p1.f1 AS point1, p2.f1 AS point2, p1.f1<->

p2.f$

FROM POINT_TBL p1, POINT_TBL p2
ORDER BY dist, point1 using <<, point2 using <<;
thirtysix|point1 |point2 | dist
---------+----------+----------+----------------
|(10,10) |(-10,0) |22.3606797749979
|(0,0) |(-10,0) | 10

The 'dist' is not being ordered.

In geometry we have:

104c103
< |(0,0) |[(0,0),(6,6)] |(-0,0)
---

|(0,0) |[(0,0),(6,6)] |(0,0)

I am happy to see the -0 changed to zero, but this may be just on my
platform. Also:

< |(-0,0),(-20,-20)
---

|(0,0),(-20,-20)

213c212
< |(-0,2),(-14,0)
---

|(0,2),(-14,0)

221c220
< |(14,-0),(0,-34)
---

|(14,0),(0,-34)

236c235

We also have broken sorting in timespan:

QUERY: SELECT '' AS fortyfive, r1.*, r2.*
FROM TIMESPAN_TBL r1, TIMESPAN_TBL r2
WHERE r1.f1 > r2.f1
ORDER BY r1.f1, r2.f1;
fortyfive|f1 |f1
---------+-----------------------------+-----------------------------
|@ 6 years |@ 14 secs ago
|@ 5 mons |@ 14 secs ago
|@ 5 mons 12 hours |@ 14 secs ago

How long has this been broken? Any idea on a cause. Obviously it is a
sorting issue, but where?

--
Bruce Momjian maillist@candle.pha.pa.us

--
Bruce Momjian
maillist@candle.pha.pa.us

Hi,

I'm seeing similar problems, mainly due to failure to sort correctly
even though there is an "order by" clause.

I did a few tests and found that the sort sort seemed to fail when there
were multiple columns in the "order by" clause. (Not conclusive)

I don't know when it 1st appeared as I've been trying to compile on
SPARC-Linux for the past few attempts and this is the 1st time I've
had a fully working package to run the regression tests on!!

Sort is now fixed. When I added UNION, I needed to add UNIQUE from
optimizer, so I added a SortClause node to the routine. Turns out it
was NULL'ing it for every sort field. Should work now.

--
Bruce Momjian
maillist@candle.pha.pa.us

I'm seeing similar problems, mainly due to failure to sort correctly
even though there is an "order by" clause.

I did a few tests and found that the sort sort seemed to fail when there
were multiple columns in the "order by" clause. (Not conclusive)

This is a huge help. I think I have found it. I just overhauled the
readfunc/outfunc code, so it was now very clear that was in the
Query.sortClause.

Your hint that the it fails when there is more than one sort identifier
was the trick.

Ah, Keith beat me to the test :) fwiw, the problem was introduced between 971227
and 980101...

- Tom

Bruce Momjian <maillist@candle.pha.pa.us>

emkxp01@mtcc.demon.co.uk

Hi,

I'm seeing similar problems, mainly due to failure to sort correctly
even though there is an "order by" clause.

I did a few tests and found that the sort sort seemed to fail when there
were multiple columns in the "order by" clause. (Not conclusive)

I don't know when it 1st appeared as I've been trying to compile on
SPARC-Linux for the past few attempts and this is the 1st time I've
had a fully working package to run the regression tests on!!

Sort is now fixed. When I added UNION, I needed to add UNIQUE from
optimizer, so I added a SortClause node to the routine. Turns out it
was NULL'ing it for every sort field. Should work now.

Thanks for the quick response, I'm building the new code now so will know
in the morning how it stands.

I'm building the whole thing with -O instead of -O2 to see if it helps
with some of the other errors I'm seeing. ( an old problem with gcc and
the SPARC processor makes me suspicious)

Later...

The sorting problems are fixes but I'm still getting many fails.

Will investigate...

Keith.