From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Koju Iijima <koju(at)fast(dot)fujitsu(dot)com(dot)au>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: contribution: namespace.sql |
Date: | 2004-09-10 22:49:22 |
Message-ID: | 3713.1094856562@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Uh, opinions on this? We don't normally test every feature of a
> command, do we?
It seemed a tad excessive to me, at least for routine regression
testing. What do you think of making it a separate test script and
adding it to "make bigcheck", as we did once with the numeric_big tests?
Also, the tests themselves are missing some bets. For instance,
inserting identical rows into the different testschmtbl's means you
couldn't easily tell if the SELECTs were returning rows from the wrong
table. I'd be inclined to use visibly different data, say (1,2) in
schm1.testschmtbl and (2,1) in public.testschmtbl.
I'd prefer also that the tests for an extremely SQL-standard feature not
rely on anything as not-standard as the contrib autoinc() trigger. The
autoinc behavior exhibited by the test is a bug if you ask me, and it
shouldn't be memorialized as correct behavior by a mainstream regression
test ... especially not when the test doesn't make it clear that it's
actually testing autoinc's misbehavior and not that of serial sequences.
(I had to read it about three times before realizing that the results
were not evidence of a serial-sequence problem...)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-09-11 00:06:47 | Re: pgxs default installation + various fixes |
Previous Message | Bruce Momjian | 2004-09-10 22:34:42 | Re: [HACKERS] more dirmod CYGWIN |