contribution: namespace.sql

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 ordinary user 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 this email 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 email unsubscribe@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