Thread: Re: [COMMITTERS] pgsql: /contrib/cube improvements: Update the calling convention for
Re: [COMMITTERS] pgsql: /contrib/cube improvements: Update the calling convention for
From
Tom Lane
Date:
momjian@postgresql.org (Bruce Momjian) writes:
> Log Message:
> -----------
> /contrib/cube improvements:
Should I point out that the buildfarm universally reports failure?
regards, tom lane
Can you point to me where I can get a regression diff for a failed build. For the install-checks that I looked at on the buildfarm, I see: ============== running regression test queries ============== test cube ... ok Josh Tom Lane wrote: > momjian@postgresql.org (Bruce Momjian) writes: > >> Log Message: >> ----------- >> /contrib/cube improvements: >> > > Should I point out that the buildfarm universally reports failure? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
Re: [COMMITTERS] pgsql: /contrib/cube improvements: Update the calling convention for
From
Tom Lane
Date:
Joshua Reich <josh@root.net> writes:
> Can you point to me where I can get a regression diff for a failed
> build.
It's all on the webpage, just scroll down ...
regards, tom lane
Ok. If I understand this correctly, earthdistance required cube. So, I'll fix the test for earthdistance to work with the new cube code. The problem is that there are new functions in cube.sql, so the output is now different and breaks the diff (to state the obvious). Josh Reich Tom Lane wrote: > Joshua Reich <josh@root.net> writes: > >> Can you point to me where I can get a regression diff for a failed >> build. >> > > It's all on the webpage, just scroll down ... > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org >
Stating the obvious, again - attached is my patch for earthdistance. Apologies for breaking the build. Josh Joshua Reich wrote: > Ok. If I understand this correctly, earthdistance required cube. So, > I'll fix the test for earthdistance to work with the new cube code. > > The problem is that there are new functions in cube.sql, so the output > is now different and breaks the diff (to state the obvious). > > Josh Reich > > > Tom Lane wrote: >> Joshua Reich <josh@root.net> writes: >> >>> Can you point to me where I can get a regression diff for a failed >>> build. >>> >> >> It's all on the webpage, just scroll down ... >> >> regards, tom lane >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 4: Have you searched our list archives? >> >> http://archives.postgresql.org >> > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly ? earthdistance.sql ? regression.diffs ? regression.out ? results Index: expected/earthdistance.out =================================================================== RCS file: /projects/cvsroot/pgsql/contrib/earthdistance/expected/earthdistance.out,v retrieving revision 1.9 diff -c -r1.9 earthdistance.out *** expected/earthdistance.out 14 Mar 2006 22:48:18 -0000 1.9 --- expected/earthdistance.out 26 Jul 2006 03:48:34 -0000 *************** *** 8,14 **** \set ECHO none psql:../cube/cube.sql:10: NOTICE: type "cube" is not yet defined DETAIL: Creating a shell type definition. ! psql:../cube/cube.sql:15: NOTICE: argument type cube is only a shell -- -- The radius of the Earth we are using. -- --- 8,16 ---- \set ECHO none psql:../cube/cube.sql:10: NOTICE: type "cube" is not yet defined DETAIL: Creating a shell type definition. ! psql:../cube/cube.sql:14: NOTICE: return type cube is only a shell ! psql:../cube/cube.sql:18: NOTICE: return type cube is only a shell ! psql:../cube/cube.sql:23: NOTICE: argument type cube is only a shell -- -- The radius of the Earth we are using. --
Joshua Reich <josh@root.net> writes:
>> The problem is that there are new functions in cube.sql, so the output
>> is now different and breaks the diff (to state the obvious).
Actually, the new theory on this is that you should explicitly create
a shell type first:
CREATE TYPE cube;
and then create the functions, and then make the type "for real".
This will still involve a change in the earthdistance expected
output (down to zero expected NOTICEs) but if we're gonna fix it
then let's fix it right.
regards, tom lane
Tom Lane wrote: > Joshua Reich <josh@root.net> writes: > >> The problem is that there are new functions in cube.sql, so the output > >> is now different and breaks the diff (to state the obvious). > > Actually, the new theory on this is that you should explicitly create > a shell type first: > > CREATE TYPE cube; > > and then create the functions, and then make the type "for real". > > This will still involve a change in the earthdistance expected > output (down to zero expected NOTICEs) but if we're gonna fix it > then let's fix it right. OK, I will wait for the next patch. Funny I tested the cube regression test, but not earthdistance. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Tom Lane wrote: >> Joshua Reich <josh@root.net> writes: >>>> The problem is that there are new functions in cube.sql, so the output >>>> is now different and breaks the diff (to state the obvious). >> Actually, the new theory on this is that you should explicitly create >> a shell type first: >> >> CREATE TYPE cube; >> >> and then create the functions, and then make the type "for real". >> >> This will still involve a change in the earthdistance expected >> output (down to zero expected NOTICEs) but if we're gonna fix it >> then let's fix it right. > > OK, I will wait for the next patch. Funny I tested the cube regression > test, but not earthdistance. FYI: the buildfarm-script has a "no reporting" mode and can use preexisting sourcetrees - that's what I regulary use to test patches and modifications to the source. Stefan
I'm not sure exactly what to do here. I tried simply doing CREATE TYPE cube; But I still get NOTICE's to the effect of "return type cube is only a shell" or "argument type cube is only a shell". I'm not sure how to do this to get zero NOTICES. Advice appreciated. Josh Reich Tom Lane wrote: > Joshua Reich <josh@root.net> writes: >>> The problem is that there are new functions in cube.sql, so the output >>> is now different and breaks the diff (to state the obvious). > > Actually, the new theory on this is that you should explicitly create > a shell type first: > > CREATE TYPE cube; > > and then create the functions, and then make the type "for real". > > This will still involve a change in the earthdistance expected > output (down to zero expected NOTICEs) but if we're gonna fix it > then let's fix it right. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend -- Joshua Reich Finance and Corporate Development ROOT Exchange, A Division of ROOT Markets 601 W. 26th St. / Suite 1500 New York, NY 10001 W - (212) 645 6320 x 7101 M / T - (646) 427 7959 E - josh@rootexchange.com
Joshua Reich <josh@root.net> writes:
> I'm not sure exactly what to do here. I tried simply doing
> CREATE TYPE cube;
> But I still get NOTICE's to the effect of "return type cube is only a
> shell" or "argument type cube is only a shell".
Hmm ... I remembered that we'd discussed suppressing those NOTICEs,
but I guess we didn't actually do it.
> I'm not sure how to do this to get zero NOTICES.
I think what I'd suggest is making earthdistance do
SET client_min_messages = warning;include the fileRESET client_min_messages;
This will avoid any future flap in the test output if we do remove
those notices.
regards, tom lane
I wrote: > > I have applied this and made an attempt to fix > cube/expected/cube_1.out - we will still need to keep an eye on the > various cube tests. > It looks like with the current tests we will need at least one more possible results file (gazelle and asp on buildfarm agree about negative zero but disagree about ordering, so we would need to handle both variants which were previously handed in just cube_1.out). That would make four for this little module. Is it just me or does that seem excessive? Can we possibly simplify things a bit? cheers andrew
I am uncomfortable with the fact that the ordering is different on different architectures. AFAIK, all I did was port the ordering function from V0 to V1. Short of me continually submitting patches until I fix it, is there an easier way, or some pointers as to what I should be looking for in the code? The function in question, I believe, is cube_cmp_v0(). Josh Andrew Dunstan wrote: > I wrote: > >> >> I have applied this and made an attempt to fix >> cube/expected/cube_1.out - we will still need to keep an eye on the >> various cube tests. >> > > It looks like with the current tests we will need at least one more > possible results file (gazelle and asp on buildfarm agree about negative > zero but disagree about ordering, so we would need to handle both > variants which were previously handed in just cube_1.out). That would > make four for this little module. Is it just me or does that seem > excessive? Can we possibly simplify things a bit? > > cheers > > andrew -- Joshua Reich Finance and Corporate Development ROOT Exchange, A Division of ROOT Markets 601 W. 26th St. / Suite 1500 New York, NY 10001 W - (212) 645 6320 x 7101 M / T - (646) 427 7959 E - josh@rootexchange.com
Is this being worked on? --------------------------------------------------------------------------- Tom Lane wrote: > Joshua Reich <josh@root.net> writes: > > I'm not sure exactly what to do here. I tried simply doing > > CREATE TYPE cube; > > > But I still get NOTICE's to the effect of "return type cube is only a > > shell" or "argument type cube is only a shell". > > Hmm ... I remembered that we'd discussed suppressing those NOTICEs, > but I guess we didn't actually do it. > > > I'm not sure how to do this to get zero NOTICES. > > I think what I'd suggest is making earthdistance do > > SET client_min_messages = warning; > include the file > RESET client_min_messages; > > This will avoid any future flap in the test output if we do remove > those notices. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> Is this being worked on?
I think we dealt with that already.
regards, tom lane