Resent-From: POSTGRES mailing list <postman@postgres.Berkeley.EDU>
Resent-Message-Id: <199408301635.JAA04295@nobozo.CS.Berkeley.EDU>
Sender: owner-postman@postgres.Berkeley.EDU
Date: Tue, 30 Aug 94 17:34:39 +0200
From: tom@basil.icce.rug.nl (Tom R.Hageman)
Message-Id: <9408301534.AA00535@basil.icce.rug.nl>
To: POSTGRES mailing list <postgres@postgres.Berkeley.EDU>
Subject: 4.2 regression test
Resent-To: postgres-redist@postgres.Berkeley.EDU
Resent-Date: Tue, 30 Aug 94 09:35:03 -0700
Resent-XMts: smtp

Hi postgurus,

While porting postgres 4.2 to NEXTSTEP I ran into trouble with the regression
tests, which I think is due to a bug in the test scripts.  Here is a
description of my problems.  Near the end of "regress/queries.source" we find 

the following queries:

	/*
	 * SECURITY CRUFT
	 */
	replace pg_class (relacl="{}")
		where pg_class.relname !~ "pg_*"::text
	\g
	replace pg_user (usesuper="f"::bool) where pg_user.usename = "_USER_"
	\g

As far as I understand it, this revokes all access privileges for all
user-created classes.  The script then ends with creating and manipulating
a new class "myclass0" with no trouble.  So far so good.

My problems start with the next phase of the regression test, which is the 

iportal test.  This tries to access the class "iportaltest" and fails with a 

read access error.  This seems the right behaviour to me, since its access list 

has just been set to an empty list "{}" (as opposed to NULL).
(Frankly, I don't understand how any postgres 4.2 ever made it through the 

regression test past this point...)

So I propose the following patch to solve this:

diff -c -2 -r1.1.1.2 queries.source
*** 1.1.1.2     1994/05/30 19:08:23
--- queries.source      1994/08/30 15:23:49
***************
*** 2442,2443 ****
--- 2442,2459 ----
  append myclass0 (a=100)
  \g
+ 

+ /* [TRH 25-Aug-94] Undo security cruft, or else the subsequent operations
+    on non-system catalogs in the regression test will fail due to insufficient
+    access privileges. (how postgres 4.2 ever passed the test past this point
+    in the first place is a mystery to me, since this seems the right behaviour;
+    nearly all access lists being empty -- as opposed to being NULL...) */
+ 

+ replace pg_class (relacl=NULL) where pg_class.relacl = "{}"
+ \g
+ /* [TRH 25-Aug-94] Just to be sure, just in case the testing user is postgres.
+    (if it is missing, subsequent administrative work will fail.)
+    NOTE: use the literal name postgres here instead of _ USER _ to avoid
+    giving a mortal user privileges in case the testing user aint postgres. */
+ 

+ replace pg_user (usesuper="t"::bool) where pg_user.usename = "postgres"
+ \g

Comments, anyone?

Regards,
Tom.

--
__/__/__/__/  Tom Hageman   <tom@basil.icce.rug.nl>   [NeXTMail accepted]
  __/ __/_/
 __/__/__/          "...to baldly go where no one has gone before."
__/  _/_/                                             -- star trek TNG

==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU"

   If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================