Thread: contribution: namespace.sql
Dear community, We found that one of RT items "namespace" has only few test cases. So I added more test cases to test whatever written in the document (chap 5.8). I tried to negate the explanation of chap5.8 and to find any faults. But no errors were found. I got the diff against the CVS HEAD. I hope applied. Thank you! koju ---------------------------------------------------------------------------- --- Koju Iijima Software Engineer Fujitsu Australia Software Technology Address: 14 Rodborough Road, Frenchs Forest NSW 2086 Tel: +61 2 9452 9076 Fax: +61 2 9975 2899 Email: koju@fast.fujitsu.com.au Web site: www.fastware.com ---------------------------------------------------------------------------- --- This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinaryuser of the email address to which it was addressed and may contain copyright and/or legally privileged information.No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive thisemail in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please emailunsubscribe@fast.fujitsu.com.au
Attachment
Uh, opinions on this? We don't normally test every feature of a command, do we? --------------------------------------------------------------------------- Koju Iijima wrote: > Dear community, > > We found that one of RT items "namespace" has only few test cases. > So I added more test cases to test whatever written in the document (chap > 5.8). > I tried to negate the explanation of chap5.8 and to find any faults. But no > errors were found. > > I got the diff against the CVS HEAD. > > I hope applied. > > Thank you! > > koju > > ---------------------------------------------------------------------------- > --- > Koju Iijima > > Software Engineer > Fujitsu Australia Software Technology > Address: 14 Rodborough Road, Frenchs Forest NSW 2086 > Tel: +61 2 9452 9076 > Fax: +61 2 9975 2899 > Email: koju@fast.fujitsu.com.au > Web site: www.fastware.com > ---------------------------------------------------------------------------- > --- > This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinaryuser of the email address to which it was addressed and may contain copyright and/or legally privileged information.No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive thisemail in error, please return to sender. Thank you. > > If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please emailunsubscribe@fast.fujitsu.com.au > [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 3: 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 | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.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
Tom Lane wrote: > 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? I'm not sure I see the point: I would guess that the rate at which we're expanding the regression tests is slower than the rate of performance increase of the average machine someone is running Postgres on (so in a sense the regression tests are speeding up over time). If at some point we add some regression tests that take a considerably longer amount of time to run, this sounds good -- I just don't think we've reached that point yet. -Neil