grant/revoke bug with delete/update

Looks very nice, but we can't apply it during beta. Only bug fixes, and
this looks a little tricky. We can try it for 7.1. Maybe you can get
us a 7.0 based patch.

Hi,

first I'm sorry to not fill the form, I'm too lazy, and it's not platform
nor version dependent AFAIK.

I recently posted a question (on Feb 23rd) to pgsql-sql concerning the
fact that update and insert are considered the same thing when you modify
permissions with grant and revoke. (Maybe it was the wrong place to post
it.)

for example a "grant delete" also grants "update" which is completely
wrong. More importantly the user is not informed, and this could lead to
VERY IMPORTANT SECURITY PROBLEMS, like someone who should only be able to
update existing records, have the permission to delete all records...

I've read postgresql documentation, especially the grant and revoke
manpages, and I've found no mention of this bug, which is IMHO a Big
Mistake (tm).

attached to this message you'll find a patch for version 6.5.2 wich
differentiate delete and update, because before they were considered as
"write". The patch only modifies .c .y and .h files, but no documentation.

the new acl rights look like: arRdu
a for append
r for read
R for rules
d for delete
u for update

instead of: arwR
a for append
r for read
w for update AND delete
R for rules

This patch seems to work at least with what I've tested, you'll find a
test session at the end of this message.

I hope this patch will help and that it will be easy to incorporate it in
7.0, which I haven't the time to do for now.

And for the bug report I posted on Feb 23rd on "drop user" which keeps the
user's acl in the database, and the deleted user id being reused, I've not
done anything, but I consider this a major problem. Please consider it for
a next version.

Because I'm not an expert, I suggest you remove gram.c before applying the
patch, in order for this file to be generated again from gram.y, but maybe
this is not necessary.

I'd be very pleased if some people could test this more than I can,
because I don't use postgresql intensively with special permissions.

I'm not sure for some parts of the patch, especially in execMain.c
so if a postgresql hacker could examine it, this would be fine.

dump of test session:
---------------------

------- CUT -------

template1=> create database db;
CREATEDB
template1=> create user john;
CREATE USER
template1=> \connect db
connecting to new database: db
db=> create table t (id INT4, name TEXT);
CREATE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | |
+----------+--------------------------+
db=> grant all on t to john;
CHANGE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=arduR"} |
+----------+--------------------------+
db=> \connect db john
connecting to new database: db as user: john
db=> insert into t (id, name) values (1, 'xxx');
INSERT 18560 1
db=> update t set name = 'yyy' where id=1;
UPDATE 1
db=> select * from t;
id|name
--+----
1|yyy
(1 row)

db=> delete from t;
DELETE 1
db=> select * from t;
id|name
--+----
(0 rows)

db=> insert into t (id, name) values (1, 'xxx');
INSERT 18561 1
db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke update on t from john;
CHANGE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=ardR"} |
+----------+--------------------------+
db=> \connect db john;
connecting to new database: db as user: john
db=> insert into t (id, name) values (2, 'yyy');
INSERT 18592 1
db=> update t set name='modified by john' where id=2;
ERROR: t: Permission denied.
db=> delete from t where id=2;
DELETE 1
db=> select * from t;
id|name
--+----
1|xxx
(1 row)

db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke insert on t from john;
CHANGE
db=> \connect db john;
connecting to new database: db as user: john
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=rdR"} |
+----------+--------------------------+
db=> insert into t (id, name) values (3, 'I try to insert something');
ERROR: t: Permission denied.
db=> delete from t;
DELETE 1
db=> select * from t;
id|name
--+----
(0 rows)

db=> \connect db postgres
connecting to new database: db as user: postgres
db=> insert into t (id, name) values (1, 'xxx');
INSERT 18624 1
db=> \connect db john;
connecting to new database: db as user: john
db=> update t set name='john' where id =1;
ERROR: t: Permission denied.
db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke delete on t from john;
CHANGE
db=> grant update on t to john;
CHANGE
db=> \connect db john;
connecting to new database: db as user: john
db=> delete from t;
ERROR: t: Permission denied.
db=> update t set name='john' where id=1;
UPDATE 1
db=> select * from t;
id|name
--+----
1|john
(1 row)

------- CUT -------

Thank you for reading.

bye,

Jerome ALET - alet@unice.fr - http://cortex.unice.fr/~jerome
Faculte de Medecine de Nice - http://noe.unice.fr - Tel: 04 93 37 76 30
28 Avenue de Valombrose - 06107 NICE Cedex 2 - FRANCE

Content-Description: the 6.5.2 patch

diff -urbw postgresql-6.5.2/src/backend/catalog/aclchk.c postgresql-6.5.2-patched/src/backend/catalog/aclchk.c
--- postgresql-6.5.2/src/backend/catalog/aclchk.c	Mon Aug  2 07:56:53 1999
+++ postgresql-6.5.2-patched/src/backend/catalog/aclchk.c	Wed Mar  1 16:39:44 2000
@@ -381,7 +381,7 @@
* pg_database table, there is still additional permissions
* checking in dbcommands.c
*/
-		if ((mode & ACL_WR) || (mode & ACL_AP))
+		if (mode & ACL_AP)
return ACLCHECK_OK;
}

@@ -390,7 +390,7 @@
* pg_shadow.usecatupd is set.	(This is to let superusers protect
* themselves from themselves.)
*/
-	if (((mode & ACL_WR) || (mode & ACL_AP)) &&
+	if ((mode & ACL_AP) &&
!allowSystemTableMods && IsSystemRelationName(relname) &&
!((Form_pg_shadow) GETSTRUCT(tuple))->usecatupd)
{
diff -urbw postgresql-6.5.2/src/backend/commands/command.c postgresql-6.5.2-patched/src/backend/commands/command.c
--- postgresql-6.5.2/src/backend/commands/command.c	Mon Aug  2 07:56:57 1999
+++ postgresql-6.5.2-patched/src/backend/commands/command.c	Wed Mar  1 16:30:23 2000
@@ -524,7 +524,9 @@
if (lockstmt->mode == AccessShareLock)
aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), ACL_RD);
else
-		aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), ACL_WR);
+		/* do we really need to have all these permissions at the same time ? */
+		/* shouldn't we test lockstmt->mode first ? */
+		aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), (ACL_AP | ACL_DE | ACL_UP));

if (aclresult != ACLCHECK_OK)
elog(ERROR, "LOCK TABLE: permission denied");
diff -urbw postgresql-6.5.2/src/backend/commands/copy.c postgresql-6.5.2-patched/src/backend/commands/copy.c
--- postgresql-6.5.2/src/backend/commands/copy.c	Sat Jul  3 02:32:39 1999
+++ postgresql-6.5.2-patched/src/backend/commands/copy.c	Wed Mar  1 16:30:35 2000
@@ -242,7 +242,8 @@
FILE	   *fp;
Relation	rel;
extern char *UserName;		/* defined in global.c */
-	const AclMode required_access = from ? ACL_WR : ACL_RD;
+	/* why should we need other permissions than APPEND ? */
+	const AclMode required_access = from ? ACL_AP : ACL_RD;
int			result;

rel = heap_openr(relname);
diff -urbw postgresql-6.5.2/src/backend/commands/sequence.c postgresql-6.5.2-patched/src/backend/commands/sequence.c
--- postgresql-6.5.2/src/backend/commands/sequence.c	Mon Aug  2 07:56:59 1999
+++ postgresql-6.5.2-patched/src/backend/commands/sequence.c	Wed Mar  1 16:31:05 2000
@@ -314,7 +314,8 @@
Form_pg_sequence seq;

#ifndef NO_SECURITY
-	if (pg_aclcheck(seqname, getpgusername(), ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than UPDATE permission ? */
+	if (pg_aclcheck(seqname, getpgusername(), ACL_UP) != ACLCHECK_OK)
elog(ERROR, "%s.setval: you don't have permissions to set sequence %s",
seqname, seqname);
#endif
diff -urbw postgresql-6.5.2/src/backend/commands/user.c postgresql-6.5.2-patched/src/backend/commands/user.c
--- postgresql-6.5.2/src/backend/commands/user.c	Mon Aug  2 07:56:59 1999
+++ postgresql-6.5.2-patched/src/backend/commands/user.c	Wed Mar  1 16:31:38 2000
@@ -115,7 +115,7 @@
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR | ACL_AP) != ACLCHECK_OK)
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_AP | ACL_DE | ACL_UP) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "defineUser: user \"%s\" does not have SELECT and INSERT privilege for \"%s\"",
@@ -227,7 +227,8 @@
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than UPDATE ? */
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_UP) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "alterUser: user \"%s\" does not have SELECT and UPDATE privilege for \"%s\"",
@@ -329,11 +330,12 @@
BeginTransactionBlock();

/*
-	 * Make sure the user attempting to create a user can delete from the
+	 * Make sure the user attempting to delete a user can delete from the
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than DELETE ? */
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_DE) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "removeUser: user \"%s\" does not have SELECT and DELETE privilege for \"%s\"",
diff -urbw postgresql-6.5.2/src/backend/executor/execMain.c postgresql-6.5.2-patched/src/backend/executor/execMain.c
--- postgresql-6.5.2/src/backend/executor/execMain.c	Thu Jun 17 17:15:49 1999
+++ postgresql-6.5.2-patched/src/backend/executor/execMain.c	Wed Mar  1 18:31:31 2000
@@ -464,14 +464,16 @@
switch (operation)
{
case CMD_INSERT:
-					ok = ((aclcheck_result = CHECK(ACL_AP)) == ACLCHECK_OK) ||
-						((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
+					ok = ((aclcheck_result = CHECK(ACL_AP)) == ACLCHECK_OK);
opstr = "append";
break;
case CMD_DELETE:
+					ok = ((aclcheck_result = CHECK(ACL_DE)) == ACLCHECK_OK);
+					opstr = "delete";
+					break;
case CMD_UPDATE:
-					ok = ((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
-					opstr = "write";
+					ok = ((aclcheck_result = CHECK(ACL_UP)) == ACLCHECK_OK);
+					opstr = "update";
break;
default:
elog(ERROR, "ExecCheckPerms: bogus operation %d",
@@ -508,8 +510,9 @@
StrNCpy(rname.data,
((Form_pg_class) GETSTRUCT(htup))->relname.data,
NAMEDATALEN);
-			ok = ((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
-			opstr = "write";
+			/* is it the right thing to do ? */
+			ok = ((aclcheck_result = CHECK((ACL_AP | ACL_DE | ACL_UP))) == ACLCHECK_OK);
+			opstr = "write";	/* unused ? */
if (!ok)
elog(ERROR, "%s: %s", rname.data, aclcheck_error_strings[aclcheck_result]);
}
diff -urbw postgresql-6.5.2/src/backend/parser/gram.y postgresql-6.5.2-patched/src/backend/parser/gram.y
--- postgresql-6.5.2/src/backend/parser/gram.y	Tue Sep 14 08:07:35 1999
+++ postgresql-6.5.2-patched/src/backend/parser/gram.y	Wed Mar  1 16:33:34 2000
@@ -1694,11 +1694,11 @@

privileges:  ALL PRIVILEGES
{
-				 $$ = aclmakepriv("rwaR",0);
+				 $$ = aclmakepriv("raduR",0);
}
| ALL
{
-				 $$ = aclmakepriv("rwaR",0);
+				 $$ = aclmakepriv("raduR",0);
}
| operation_commalist
{
@@ -1726,11 +1726,11 @@
}
| UPDATE
{
-						$$ = ACL_MODE_WR_CHR;
+						$$ = ACL_MODE_UP_CHR;
}
| DELETE
{
-						$$ = ACL_MODE_WR_CHR;
+						$$ = ACL_MODE_DE_CHR;
}
| RULE
{
diff -urbw postgresql-6.5.2/src/backend/parser/parse.h postgresql-6.5.2-patched/src/backend/parser/parse.h
--- postgresql-6.5.2/src/backend/parser/parse.h	Thu Sep 16 02:23:39 1999
+++ postgresql-6.5.2-patched/src/backend/parser/parse.h	Wed Mar  1 18:34:46 2000
@@ -29,236 +29,236 @@
RuleStmt			*rstmt;
InsertStmt			*astmt;
} YYSTYPE;
-#define	ABSOLUTE	257
-#define	ACTION	258
-#define	ADD	259
-#define	ALL	260
-#define	ALTER	261
-#define	AND	262
-#define	ANY	263
-#define	AS	264
-#define	ASC	265
-#define	BEGIN_TRANS	266
-#define	BETWEEN	267
-#define	BOTH	268
-#define	BY	269
-#define	CASCADE	270
-#define	CASE	271
-#define	CAST	272
-#define	CHAR	273
-#define	CHARACTER	274
-#define	CHECK	275
-#define	CLOSE	276
-#define	COALESCE	277
-#define	COLLATE	278
-#define	COLUMN	279
-#define	COMMIT	280
-#define	CONSTRAINT	281
-#define	CREATE	282
-#define	CROSS	283
-#define	CURRENT	284
-#define	CURRENT_DATE	285
-#define	CURRENT_TIME	286
-#define	CURRENT_TIMESTAMP	287
-#define	CURRENT_USER	288
-#define	CURSOR	289
-#define	DAY_P	290
-#define	DECIMAL	291
-#define	DECLARE	292
-#define	DEFAULT	293
-#define	DELETE	294
-#define	DESC	295
-#define	DISTINCT	296
-#define	DOUBLE	297
-#define	DROP	298
-#define	ELSE	299
-#define	END_TRANS	300
-#define	EXCEPT	301
-#define	EXECUTE	302
-#define	EXISTS	303
-#define	EXTRACT	304
-#define	FALSE_P	305
-#define	FETCH	306
-#define	FLOAT	307
-#define	FOR	308
-#define	FOREIGN	309
-#define	FROM	310
-#define	FULL	311
-#define	GLOBAL	312
-#define	GRANT	313
-#define	GROUP	314
-#define	HAVING	315
-#define	HOUR_P	316
-#define	IN	317
-#define	INNER_P	318
-#define	INSENSITIVE	319
-#define	INSERT	320
-#define	INTERSECT	321
-#define	INTERVAL	322
-#define	INTO	323
-#define	IS	324
-#define	ISOLATION	325
-#define	JOIN	326
-#define	KEY	327
-#define	LANGUAGE	328
-#define	LEADING	329
-#define	LEFT	330
-#define	LEVEL	331
-#define	LIKE	332
-#define	LOCAL	333
-#define	MATCH	334
-#define	MINUTE_P	335
-#define	MONTH_P	336
-#define	NAMES	337
-#define	NATIONAL	338
-#define	NATURAL	339
-#define	NCHAR	340
-#define	NEXT	341
-#define	NO	342
-#define	NOT	343
-#define	NULLIF	344
-#define	NULL_P	345
-#define	NUMERIC	346
-#define	OF	347
-#define	ON	348
-#define	ONLY	349
-#define	OPTION	350
-#define	OR	351
-#define	ORDER	352
-#define	OUTER_P	353
-#define	PARTIAL	354
-#define	POSITION	355
-#define	PRECISION	356
-#define	PRIMARY	357
-#define	PRIOR	358
-#define	PRIVILEGES	359
-#define	PROCEDURE	360
-#define	PUBLIC	361
-#define	READ	362
-#define	REFERENCES	363
-#define	RELATIVE	364
-#define	REVOKE	365
-#define	RIGHT	366
-#define	ROLLBACK	367
-#define	SCROLL	368
-#define	SECOND_P	369
-#define	SELECT	370
-#define	SET	371
-#define	SUBSTRING	372
-#define	TABLE	373
-#define	TEMP	374
-#define	TEMPORARY	375
-#define	THEN	376
-#define	TIME	377
-#define	TIMESTAMP	378
-#define	TIMEZONE_HOUR	379
-#define	TIMEZONE_MINUTE	380
-#define	TO	381
-#define	TRAILING	382
-#define	TRANSACTION	383
-#define	TRIM	384
-#define	TRUE_P	385
-#define	UNION	386
-#define	UNIQUE	387
-#define	UPDATE	388
-#define	USER	389
-#define	USING	390
-#define	VALUES	391
-#define	VARCHAR	392
-#define	VARYING	393
-#define	VIEW	394
-#define	WHEN	395
-#define	WHERE	396
-#define	WITH	397
-#define	WORK	398
-#define	YEAR_P	399
-#define	ZONE	400
-#define	TRIGGER	401
-#define	COMMITTED	402
-#define	SERIALIZABLE	403
-#define	TYPE_P	404
-#define	ABORT_TRANS	405
-#define	ACCESS	406
-#define	AFTER	407
-#define	AGGREGATE	408
-#define	ANALYZE	409
-#define	BACKWARD	410
-#define	BEFORE	411
-#define	BINARY	412
-#define	CACHE	413
-#define	CLUSTER	414
-#define	COPY	415
-#define	CREATEDB	416
-#define	CREATEUSER	417
-#define	CYCLE	418
-#define	DATABASE	419
-#define	DELIMITERS	420
-#define	DO	421
-#define	EACH	422
-#define	ENCODING	423
-#define	EXCLUSIVE	424
-#define	EXPLAIN	425
-#define	EXTEND	426
-#define	FORWARD	427
-#define	FUNCTION	428
-#define	HANDLER	429
-#define	INCREMENT	430
-#define	INDEX	431
-#define	INHERITS	432
-#define	INSTEAD	433
-#define	ISNULL	434
-#define	LANCOMPILER	435
-#define	LIMIT	436
-#define	LISTEN	437
-#define	LOAD	438
-#define	LOCATION	439
-#define	LOCK_P	440
-#define	MAXVALUE	441
-#define	MINVALUE	442
-#define	MODE	443
-#define	MOVE	444
-#define	NEW	445
-#define	NOCREATEDB	446
-#define	NOCREATEUSER	447
-#define	NONE	448
-#define	NOTHING	449
-#define	NOTIFY	450
-#define	NOTNULL	451
-#define	OFFSET	452
-#define	OIDS	453
-#define	OPERATOR	454
-#define	PASSWORD	455
-#define	PROCEDURAL	456
-#define	RENAME	457
-#define	RESET	458
-#define	RETURNS	459
-#define	ROW	460
-#define	RULE	461
-#define	SEQUENCE	462
-#define	SERIAL	463
-#define	SETOF	464
-#define	SHARE	465
-#define	SHOW	466
-#define	START	467
-#define	STATEMENT	468
-#define	STDIN	469
-#define	STDOUT	470
-#define	TRUSTED	471
-#define	UNLISTEN	472
-#define	UNTIL	473
-#define	VACUUM	474
-#define	VALID	475
-#define	VERBOSE	476
-#define	VERSION	477
-#define	IDENT	478
-#define	SCONST	479
-#define	Op	480
-#define	ICONST	481
-#define	PARAM	482
-#define	FCONST	483
-#define	OP	484
-#define	UMINUS	485
-#define	TYPECAST	486
+#define	ABSOLUTE	258
+#define	ACTION	259
+#define	ADD	260
+#define	ALL	261
+#define	ALTER	262
+#define	AND	263
+#define	ANY	264
+#define	AS	265
+#define	ASC	266
+#define	BEGIN_TRANS	267
+#define	BETWEEN	268
+#define	BOTH	269
+#define	BY	270
+#define	CASCADE	271
+#define	CASE	272
+#define	CAST	273
+#define	CHAR	274
+#define	CHARACTER	275
+#define	CHECK	276
+#define	CLOSE	277
+#define	COALESCE	278
+#define	COLLATE	279
+#define	COLUMN	280
+#define	COMMIT	281
+#define	CONSTRAINT	282
+#define	CREATE	283
+#define	CROSS	284
+#define	CURRENT	285
+#define	CURRENT_DATE	286
+#define	CURRENT_TIME	287
+#define	CURRENT_TIMESTAMP	288
+#define	CURRENT_USER	289
+#define	CURSOR	290
+#define	DAY_P	291
+#define	DECIMAL	292
+#define	DECLARE	293
+#define	DEFAULT	294
+#define	DELETE	295
+#define	DESC	296
+#define	DISTINCT	297
+#define	DOUBLE	298
+#define	DROP	299
+#define	ELSE	300
+#define	END_TRANS	301
+#define	EXCEPT	302
+#define	EXECUTE	303
+#define	EXISTS	304
+#define	EXTRACT	305
+#define	FALSE_P	306
+#define	FETCH	307
+#define	FLOAT	308
+#define	FOR	309
+#define	FOREIGN	310
+#define	FROM	311
+#define	FULL	312
+#define	GLOBAL	313
+#define	GRANT	314
+#define	GROUP	315
+#define	HAVING	316
+#define	HOUR_P	317
+#define	IN	318
+#define	INNER_P	319
+#define	INSENSITIVE	320
+#define	INSERT	321
+#define	INTERSECT	322
+#define	INTERVAL	323
+#define	INTO	324
+#define	IS	325
+#define	ISOLATION	326
+#define	JOIN	327
+#define	KEY	328
+#define	LANGUAGE	329
+#define	LEADING	330
+#define	LEFT	331
+#define	LEVEL	332
+#define	LIKE	333
+#define	LOCAL	334
+#define	MATCH	335
+#define	MINUTE_P	336
+#define	MONTH_P	337
+#define	NAMES	338
+#define	NATIONAL	339
+#define	NATURAL	340
+#define	NCHAR	341
+#define	NEXT	342
+#define	NO	343
+#define	NOT	344
+#define	NULLIF	345
+#define	NULL_P	346
+#define	NUMERIC	347
+#define	OF	348
+#define	ON	349
+#define	ONLY	350
+#define	OPTION	351
+#define	OR	352
+#define	ORDER	353
+#define	OUTER_P	354
+#define	PARTIAL	355
+#define	POSITION	356
+#define	PRECISION	357
+#define	PRIMARY	358
+#define	PRIOR	359
+#define	PRIVILEGES	360
+#define	PROCEDURE	361
+#define	PUBLIC	362
+#define	READ	363
+#define	REFERENCES	364
+#define	RELATIVE	365
+#define	REVOKE	366
+#define	RIGHT	367
+#define	ROLLBACK	368
+#define	SCROLL	369
+#define	SECOND_P	370
+#define	SELECT	371
+#define	SET	372
+#define	SUBSTRING	373
+#define	TABLE	374
+#define	TEMP	375
+#define	TEMPORARY	376
+#define	THEN	377
+#define	TIME	378
+#define	TIMESTAMP	379
+#define	TIMEZONE_HOUR	380
+#define	TIMEZONE_MINUTE	381
+#define	TO	382
+#define	TRAILING	383
+#define	TRANSACTION	384
+#define	TRIM	385
+#define	TRUE_P	386
+#define	UNION	387
+#define	UNIQUE	388
+#define	UPDATE	389
+#define	USER	390
+#define	USING	391
+#define	VALUES	392
+#define	VARCHAR	393
+#define	VARYING	394
+#define	VIEW	395
+#define	WHEN	396
+#define	WHERE	397
+#define	WITH	398
+#define	WORK	399
+#define	YEAR_P	400
+#define	ZONE	401
+#define	TRIGGER	402
+#define	COMMITTED	403
+#define	SERIALIZABLE	404
+#define	TYPE_P	405
+#define	ABORT_TRANS	406
+#define	ACCESS	407
+#define	AFTER	408
+#define	AGGREGATE	409
+#define	ANALYZE	410
+#define	BACKWARD	411
+#define	BEFORE	412
+#define	BINARY	413
+#define	CACHE	414
+#define	CLUSTER	415
+#define	COPY	416
+#define	CREATEDB	417
+#define	CREATEUSER	418
+#define	CYCLE	419
+#define	DATABASE	420
+#define	DELIMITERS	421
+#define	DO	422
+#define	EACH	423
+#define	ENCODING	424
+#define	EXCLUSIVE	425
+#define	EXPLAIN	426
+#define	EXTEND	427
+#define	FORWARD	428
+#define	FUNCTION	429
+#define	HANDLER	430
+#define	INCREMENT	431
+#define	INDEX	432
+#define	INHERITS	433
+#define	INSTEAD	434
+#define	ISNULL	435
+#define	LANCOMPILER	436
+#define	LIMIT	437
+#define	LISTEN	438
+#define	LOAD	439
+#define	LOCATION	440
+#define	LOCK_P	441
+#define	MAXVALUE	442
+#define	MINVALUE	443
+#define	MODE	444
+#define	MOVE	445
+#define	NEW	446
+#define	NOCREATEDB	447
+#define	NOCREATEUSER	448
+#define	NONE	449
+#define	NOTHING	450
+#define	NOTIFY	451
+#define	NOTNULL	452
+#define	OFFSET	453
+#define	OIDS	454
+#define	OPERATOR	455
+#define	PASSWORD	456
+#define	PROCEDURAL	457
+#define	RENAME	458
+#define	RESET	459
+#define	RETURNS	460
+#define	ROW	461
+#define	RULE	462
+#define	SEQUENCE	463
+#define	SERIAL	464
+#define	SETOF	465
+#define	SHARE	466
+#define	SHOW	467
+#define	START	468
+#define	STATEMENT	469
+#define	STDIN	470
+#define	STDOUT	471
+#define	TRUSTED	472
+#define	UNLISTEN	473
+#define	UNTIL	474
+#define	VACUUM	475
+#define	VALID	476
+#define	VERBOSE	477
+#define	VERSION	478
+#define	IDENT	479
+#define	SCONST	480
+#define	Op	481
+#define	ICONST	482
+#define	PARAM	483
+#define	FCONST	484
+#define	OP	485
+#define	UMINUS	486
+#define	TYPECAST	487

extern YYSTYPE yylval;
diff -urbw postgresql-6.5.2/src/backend/parser/parse_func.c postgresql-6.5.2-patched/src/backend/parser/parse_func.c
--- postgresql-6.5.2/src/backend/parser/parse_func.c	Fri Jun 18 00:21:40 1999
+++ postgresql-6.5.2-patched/src/backend/parser/parse_func.c	Wed Mar  1 16:33:53 2000
@@ -601,7 +601,8 @@

if ((aclcheck_result = pg_aclcheck(seqrel, GetPgUserName(),
(((funcid == F_NEXTVAL) || (funcid == F_SETVAL)) ?
-						ACL_WR : ACL_RD)))
+						/* if nextval and setval are atomic, which I don't know, update should be enough */
+						ACL_UP : ACL_RD)))
!= ACLCHECK_OK)
elog(ERROR, "%s.%s: %s",
seqrel, funcname, aclcheck_error_strings[aclcheck_result]);
diff -urbw postgresql-6.5.2/src/backend/rewrite/locks.c postgresql-6.5.2-patched/src/backend/rewrite/locks.c
--- postgresql-6.5.2/src/backend/rewrite/locks.c	Sun Feb 14 00:17:44 1999
+++ postgresql-6.5.2-patched/src/backend/rewrite/locks.c	Wed Mar  1 16:34:20 2000
@@ -228,8 +228,15 @@
case CMD_INSERT:
reqperm = ACL_AP;
break;
+						case CMD_DELETE:
+							reqperm = ACL_DE;
+							break;
+						case CMD_UPDATE:
+							reqperm = ACL_UP;
+							break;
default:
-							reqperm = ACL_WR;
+							/* is it The Right Thing To Do (tm) ? */
+							reqperm = ACL_AP | ACL_DE | ACL_UP;
break;
}
else
diff -urbw postgresql-6.5.2/src/backend/rewrite/rewriteHandler.c postgresql-6.5.2-patched/src/backend/rewrite/rewriteHandler.c
--- postgresql-6.5.2/src/backend/rewrite/rewriteHandler.c	Sun Jul 11 19:54:30 1999
+++ postgresql-6.5.2-patched/src/backend/rewrite/rewriteHandler.c	Wed Mar  1 16:35:01 2000
@@ -2282,8 +2282,15 @@
case CMD_INSERT:
reqperm = ACL_AP;
break;
+				case CMD_DELETE:
+					reqperm = ACL_DE;
+					break;
+				case CMD_UPDATE:
+					reqperm = ACL_UP;
+					break;
default:
-					reqperm = ACL_WR;
+					/* is it The Right Thing To Do (tm) ? */
+					reqperm = ACL_AP | ACL_DE | ACL_UP;
break;
}

diff -urbw postgresql-6.5.2/src/backend/storage/file/fd.c postgresql-6.5.2-patched/src/backend/storage/file/fd.c
diff -urbw postgresql-6.5.2/src/backend/utils/adt/acl.c postgresql-6.5.2-patched/src/backend/utils/adt/acl.c
--- postgresql-6.5.2/src/backend/utils/adt/acl.c	Mon Aug  2 07:24:49 1999
+++ postgresql-6.5.2-patched/src/backend/utils/adt/acl.c	Wed Mar  1 16:35:53 2000
@@ -154,8 +154,11 @@
case ACL_MODE_RD_CHR:
aip->ai_mode |= ACL_RD;
break;
-			case ACL_MODE_WR_CHR:
-				aip->ai_mode |= ACL_WR;
+			case ACL_MODE_DE_CHR:
+				aip->ai_mode |= ACL_DE;
+				break;
+			case ACL_MODE_UP_CHR:
+				aip->ai_mode |= ACL_UP;
break;
case ACL_MODE_RU_CHR:
aip->ai_mode |= ACL_RU;
@@ -272,7 +275,7 @@
if (!aip)
aip = &default_aclitem;

-	p = out = palloc(strlen("group =arwR ") + 1 + NAMEDATALEN);
+	p = out = palloc(strlen("group =arRdu ") + 1 + NAMEDATALEN);
if (!out)
elog(ERROR, "aclitemout: palloc failed");
*p = '\0';
@@ -605,9 +608,8 @@
int			i;
int			l;

-	Assert(strlen(old_privlist) < 5);
-	priv = palloc(5); /* at most "rwaR" */ ;
-
+	Assert(strlen(old_privlist) < 6);
+	priv = palloc(6); /* at most "arduR" */ ;
if (old_privlist == NULL || old_privlist[0] == '\0')
{
priv[0] = new_priv;
@@ -619,7 +621,7 @@

l = strlen(old_privlist);

-	if (l == 4)
+	if (l == 5)
{							/* can't add any more privileges */
return priv;
}
diff -urbw postgresql-6.5.2/src/include/utils/acl.h postgresql-6.5.2-patched/src/include/utils/acl.h
--- postgresql-6.5.2/src/include/utils/acl.h	Fri Jul 30 19:07:22 1999
+++ postgresql-6.5.2-patched/src/include/utils/acl.h	Wed Mar  1 16:40:50 2000
@@ -54,9 +54,10 @@
#define ACL_NO			0		/* no permissions */
#define ACL_AP			(1<<0)	/* append */
#define ACL_RD			(1<<1)	/* read */
-#define ACL_WR			(1<<2)	/* write (append/delete/replace) */
-#define ACL_RU			(1<<3)	/* place rules */
-#define N_ACL_MODES		4
+#define ACL_DE			(1<<2)	/* delete */
+#define ACL_UP			(1<<3)	/* update/replace */
+#define ACL_RU			(1<<4)	/* place rules */
+#define N_ACL_MODES		5

#define ACL_MODECHG_ADD			1
#define ACL_MODECHG_DEL			2
@@ -65,7 +66,8 @@
/* change this line if you want to set the default acl permission  */
#define ACL_WORLD_DEFAULT		(ACL_NO)
/* #define		ACL_WORLD_DEFAULT		(ACL_RD|ACL_WR|ACL_AP|ACL_RU) */
-#define ACL_OWNER_DEFAULT		(ACL_RD|ACL_WR|ACL_AP|ACL_RU)
+
+#define ACL_OWNER_DEFAULT		(ACL_AP|ACL_RD|ACL_RU|ACL_DE|ACL_UP)

/*
* AclItem
@@ -118,10 +120,12 @@
#define ACL_MODECHG_ADD_CHR		'+'
#define ACL_MODECHG_DEL_CHR		'-'
#define ACL_MODECHG_EQL_CHR		'='
-#define ACL_MODE_STR			"arwR"	/* list of valid characters */
+
+#define ACL_MODE_STR			"arduR"	 /* list of valid characters */
#define ACL_MODE_AP_CHR			'a'
#define ACL_MODE_RD_CHR			'r'
-#define ACL_MODE_WR_CHR			'w'
+#define ACL_MODE_DE_CHR			'd'
+#define ACL_MODE_UP_CHR			'u'
#define ACL_MODE_RU_CHR			'R'

/* result codes for pg_aclcheck */

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Thu Mar 2 11:02:55 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA50243
for <pgsql-hackers@postgresql.org>; Thu, 2 Mar 2000 11:02:53 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Dront.DoCS.UU.SE (e99re41@Dront.DoCS.UU.SE [130.238.9.108])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id QAA19728;
Thu, 2 Mar 2000 16:58:45 +0100 (MET)
Received: from localhost (e99re41@localhost) by Dront.DoCS.UU.SE
(8.6.12/8.6.12) with ESMTP id QAA00183;
Thu, 2 Mar 2000 16:58:43 +0100
X-Authentication-Warning: Dront.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 2 Mar 2000 16:58:42 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: "Sergio A. Kessler" <sak@tribctas.gba.gov.ar>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] rpms
In-Reply-To: <38BD466F.A5492476@alumni.caltech.edu>
Message-ID: <Pine.GSO.4.02A.10003021654220.27493-100000@Dront.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.org id LAA50246

On Wed, 1 Mar 2000, Thomas Lockhart wrote:

Anyway, afaik most RPM distros of a product have one .rpm file which
has the name of the package, and then may have other .rpm files which
have qualifiers, like "-server". So in choosing which .rpm file will
be the base package, it seemed most appropriate that it be the
client-side stuff, as opposed to docs, or server (which btw can't
really be run on its own without the client stuff installed
*somewhere*), or something else.

Usually, the "base" package somehow contains what the package centers
around and the -xxx packages are supplements (like -headers, -devel,
-foointerface). Arguably, PostgreSQL centers around the database server.

Why not just name the packages postgresql-server and postgresql-client and
have no 'postgresql' as such. That should alleviate any confusion
whatsoever.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Thu Mar 2 11:14:58 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA51914
for <pgsql-hackers@postgresql.org>; Thu, 2 Mar 2000 11:14:00 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Dront.DoCS.UU.SE (e99re41@Dront.DoCS.UU.SE [130.238.9.108])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id RAA21148;
Thu, 2 Mar 2000 17:13:57 +0100 (MET)
Received: from localhost (e99re41@localhost) by Dront.DoCS.UU.SE
(8.6.12/8.6.12) with ESMTP id RAA00512;
Thu, 2 Mar 2000 17:13:55 +0100
X-Authentication-Warning: Dront.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 2 Mar 2000 17:13:55 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: =?iso-8859-2?Q?Hor=E1k_Daniel?= <horak@sit.plzen-city.cz>
cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] PostgreSQL on Solaris/SPARC with gcc
In-Reply-To:
<E33858CBACEDD3118C6700A024B3BF909955CC@exchange.mmp.plzen-city.cz>
Message-ID: <Pine.GSO.4.02A.10003021708330.27493-100000@Dront.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.org id LAA52056

On Wed, 1 Mar 2000, [iso-8859-2] Hor���k Daniel wrote:

it is caused by the fact that the symbol CurrentMemoryContext is not
exported from the main executable (postmaster). The solution is to use
"-export-dynamic" switch when linking postgres executable (it is used on
Linux).

I think it will require a new system specific makefile. The
Makefile.solaris_sparc is done for solaric_sparc_cc template. More details
can be send.

Couldn't we just test for gcc in general on any platform? For right now
you might get away with doing a little ifeq($(CC),gcc) action in the
solaris makefile, but that's bogus in the long run.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Thu Mar 2 11:23:56 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA53371
for <pgsql-hackers@postgreSQL.org>; Thu, 2 Mar 2000 11:23:47 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Dront.DoCS.UU.SE (e99re41@Dront.DoCS.UU.SE [130.238.9.108])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id RAA21736;
Thu, 2 Mar 2000 17:23:38 +0100 (MET)
Received: from localhost (e99re41@localhost) by Dront.DoCS.UU.SE
(8.6.12/8.6.12) with ESMTP id RAA00754;
Thu, 2 Mar 2000 17:23:36 +0100
X-Authentication-Warning: Dront.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 2 Mar 2000 17:23:35 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
cc: "'Tom Lane'" <tgl@sss.pgh.pa.us>, "'Jose Soares'" <jose@sferacarta.com>,
"'hackers'" <pgsql-hackers@postgreSQL.org>
Subject: Re: AW: [HACKERS] having and union in v7beta
In-Reply-To:
<219F68D65015D011A8E000006F8590C604AF7D07@sdexcsrv1.f000.d0188.sd.spardat.at>
Message-ID: <Pine.GSO.4.02A.10003021718390.27493-100000@Dront.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.org id LAA53380

On Thu, 2 Mar 2000, Zeugswetter Andreas SB wrote:

But if the two queries are the same, the union CAN be simplified,
since the union of two identical masses (I don't know the correct word here)
is still that one mass.

"set" :)

Thus 6.5 simplification is correct in this particular case.

The issue here seems to be that the queries could have side-effects, such
as

select nextval('sequence1')
union
select nextval('sequence1')

which should arguably return two distinct rows. I gotta reread SQL's
opinion on this, but I'm sure Tom has already done that. From a
mathematical point of view, I believe your assumption "lexically equal
queries yield mathematically equal sets" is wrong.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Thu Mar 2 11:32:55 2000
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA54729
for <pgsql-hackers@postgreSQL.org>; Thu, 2 Mar 2000 11:32:52 -0500 (EST)
(envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA28375
for <pgsql-hackers@postgreSQL.org>; Thu, 2 Mar 2000 17:32:51 +0100
Date: Thu, 2 Mar 2000 17:32:51 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: SPI and qCache and bug?
Message-ID: <Pine.LNX.3.96.1000302170814.3304F-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

query cache hacking continue ...

I just implement my (context-per-plan) query cache (qCache) to SPI.

Changed:

SPI_saveplan() - save plan to qcache instead to never
unallocated TopMemoryContext.

New:

SPI_saveplan_by_key() - save plan to qcache under specifited hash
key. This is needful if user define key oneself or if key must be
binary (non-string) - example Jan use any struct as hash key in RI's
triggers.)

SPI_execp_by_key() - same as SPI_execp(), but as arg is hash key
only, (again, it is needful for (example) RI).
- you not need pointer to plan, you can use key only

SPI_freeplan() - remove plan from qcache and destroy all
memory associate with plan. It is end of the TopMemoryContext
feeding :-)

Comments?

A question: I look at the current PG's SPI and (IMHO) is here a little
performance bug. Very often is used SPI_prepare() and SPI_saveplan()
together and without any relevant code between these routines. But see:

SPI_prepare() - call 2x copyObject() and copy data to procedure
context

- well, if you need pquery plans in this context it is OK, but

SPI_saveplan() - call 2x copyObject() and copy (same) data to
TopMemoryContext (or in future to qCache)

SPI_execp() - call 2x copyObject() and copy data back to current
context

- hmm, it copy twice all data, but without any efect.

IMHO is solution any SPI_prepare_and_save() and copy data only to
TopMemoryContext (or to qCache), we not need data in procedure context
(as it copy SPI_prepare), because SPI_execp() copy it to wanted context
itself.

The SPI performance will interesting if RI will in real life...

Karel

From bouncefilter Thu Mar 2 11:36:55 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA55563
for <pgsql-hackers@postgresql.org>; Thu, 2 Mar 2000 11:36:39 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA16462;
Thu, 2 Mar 2000 16:38:23 GMT
Sender: lockhart@hub.org
Message-ID: <38BE98FF.EE9978A@alumni.caltech.edu>
Date: Thu, 02 Mar 2000 16:38:23 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: "Sergio A. Kessler" <sak@tribctas.gba.gov.ar>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] rpms
References: <Pine.GSO.4.02A.10003021654220.27493-100000@Dront.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Why not just name the packages postgresql-server and postgresql-client and
have no 'postgresql' as such. That should alleviate any confusion
whatsoever.

That is possible. imho it is solving a "problem" with no clear benefit
in the end, so why bother? Just renaming packages doesn't, by name
alone, clarify which packages depend on others, doesn't clarify that
-server depends on -client, etc etc.

I'd recommend going with the current scheme for some more time, and
rather put the effort into clarifying in docs what the packages are
and which are useful for what. I'm pretty sure that Lamar has some of
this in place already, and we can see about integrating some of the
info for v7.0 docs...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Fri Mar 3 07:37:09 2000
Received: from server2.gba.gov.ar (IDENT:root@server2.gba.gov.ar
[170.155.1.6])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA99521
for <pgsql-hackers@postgresql.org>; Fri, 3 Mar 2000 07:36:07 -0500 (EST)
(envelope-from sak@tribctas.gba.gov.ar)
Received: from tribctas.gba.gov.ar (IDENT:root@server.tribctas.gba.gov.ar
[10.42.1.1])
by server2.gba.gov.ar (8.9.3/8.8.7) with ESMTP id JAA02164
for <pgsql-hackers@postgresql.org>; Fri, 3 Mar 2000 09:36:00 -0300
Received: from sergio (Sergio.tribctas.gba.gov.ar [10.42.1.64])
by tribctas.gba.gov.ar (8.9.3/8.8.7) with SMTP id JAA10125
for <pgsql-hackers@postgresql.org>; Fri, 3 Mar 2000 09:38:15 -0300
From: "Sergio A. Kessler" <sak@tribctas.gba.gov.ar>
Message-Id: <SAK.2000.03.03.qobrtjjp@sergio>
In-Reply-To: <38BE98FF.EE9978A@alumni.caltech.edu>
Date: Fri, 3 Mar 2000 09:39:32 -0300
X-Priority: 3
X-Mailer: Correo F���cil
To: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Subject: Re: [HACKERS] rpms
Content-Type: Text/Plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8Bit

Thomas Lockhart <lockhart@alumni.caltech.edu> el d���a Thu, 02 Mar 2000
16:38:23 +0000, escribi���:

Why not just name the packages postgresql-server and postgresql-client

[...]

That is possible. imho it is solving a "problem" with no clear benefit
in the end, so why bother? Just renaming packages doesn't, by name
alone, clarify which packages depend on others, doesn't clarify that
-server depends on -client, etc etc.

sorry to be picky thomas, but if the name has almost no mean
(as you imply) then why not call the package "pirindonga" ?

anyway, is not a problem for =me=, I know now what the package
contains (but I've installed the postgres rpm believing I was
installing the server, so count on me as one damnified that
ignored that there must be a package named just postgresql).

one last thing, usually users don't look at the full description
of the package before installing it, they (and I) just do
rpm -Uvh xxxxx.rpm (usually the name is self descriptive)

sergio

Bruce Momjian writes:

Looks very nice, but we can't apply it during beta. Only bug fixes, and
this looks a little tricky. We can try it for 7.1. Maybe you can get
us a 7.0 based patch.

It was me that encouraged him to send in this patch now because Karel and
I are currently talking about redoing the ACL stuff for 7.1.

I considered this a bug and the fix looks pretty straightforward. Perhaps
it should go into 7.0.1?

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sat Mar 4 12:05:05 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA67399
for <pgsql-hackers@postgresql.org>; Sat, 4 Mar 2000 12:03:39 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61651 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S407557AbQCDRC4>;
Sat, 4 Mar 2000 18:02:56 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12RI0J-0000Bg-00; Sat, 04 Mar 2000 18:06:11 +0100
Date: Sat, 4 Mar 2000 18:06:11 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Mark Jewiss <mark.jewiss@knowledge.com>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [GENERAL] Version 7.0 beta problem
In-Reply-To:
<Pine.BSO.4.21.0003031626090.13396-100000@mark.desktop.knowledge.com>
Message-ID: <Pine.LNX.4.21.0003040418470.489-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

Mark Jewiss writes:

04:25pm mark@mark:~/src/pgsql/src/bin/psql $ sudo gmake

[snip]

gcc -I../../interfaces/libpq -I../../include -I../../backend -O2 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -c mainloop.c -o mainloop.o
mainloop.c: In function `MainLoop':
mainloop.c:43: warning: variable `successResult' might be clobbered by `longjmp' or `vfork'
mainloop.c:44: warning: variable `slashCmdStatus' might be clobbered by `longjmp' or `vfork'
mainloop.c:47: warning: variable `in_quote' might be clobbered by `longjmp' or `vfork'

[etc]

I thought I had shut up those warnings by making the variables in question
volatile. There's no need to worry about them since they're re-initialized
right after the longjmp, but does anyone know how to shut up the compiler?

gcc -I../../interfaces/libpq -I../../include -I../../backend -O2 -pipe
-Wall -
Wmissing-prototypes -Wmissing-declarations -c tab-complete.c -o
tab-complete.o
tab-complete.c: In function `psql_completion':
tab-complete.c:535: `filename_completion_function' undeclared (first use
in this
function)
tab-complete.c:535: (Each undeclared identifier is reported only once
tab-complete.c:535: for each function it appears in.)
gmake: *** [tab-complete.o] Error 1
04:25pm mark@mark:~/src/pgsql/src/bin/psql $

Aye, there's the rub. One more of these and I'm yanking every trace of
readline out of psql. ;) Another configure test, another subtle functional
difference as the consequence ...

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sat Mar 4 12:04:42 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA67491
for <pgsql-hackers@postgresql.org>; Sat, 4 Mar 2000 12:04:19 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62453 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S407566AbQCDRD2>;
Sat, 4 Mar 2000 18:03:28 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12RI0j-0000Bm-00; Sat, 04 Mar 2000 18:06:37 +0100
Date: Sat, 4 Mar 2000 18:06:37 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
In-Reply-To: <14322.951940687@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0003040427210.489-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

Tom Lane writes:

There's another issue, which is that the routines that implement
operations for a particular type are generally named after the type's
internal name. I trust you are not going to propose that we find a way
to put spaces into C function names ;-). It seems to me that the
confusion created by having support code named differently from the
type's internal name is just as bad as having the internal name
different from the external name.

This being the case, it seems like "bit_varying" might be a reasonable
compromise for the internal name, and that should work already...

Okay, that's the first reasonable argument I've heard in this thread, and
I'll buy it. Since correspondence between internal type names and function
names *is* achievable without hacks we might as well go for this one.

In turn I'm thinking that it might be nice to have a backend function like
format_type(name[, int4]) that formats an internal type and any size
modifier for client consumption, like

format_type('varchar', 8) => "CHARACTER VARYING(8)"
format_type('my type') => "\"my type\""
format_type('numeric', {xxx}) => "NUMERIC(9,2)"

That could put an end to keeping track of backend implementation details
in psql, pg_dump, and friends.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sat Mar 4 12:04:29 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA67492
for <pgsql-hackers@postgresql.org>; Sat, 4 Mar 2000 12:04:20 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62506 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S407557AbQCDRDa>;
Sat, 4 Mar 2000 18:03:30 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12RI0p-0000Bo-00; Sat, 04 Mar 2000 18:06:43 +0100
Date: Sat, 4 Mar 2000 18:06:43 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE
In-Reply-To: <Pine.LNX.3.96.1000302161415.3304D-100000@ara.zf.jcu.cz>
Message-ID: <Pine.LNX.4.21.0003040434200.489-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

Karel Zak - Zakkr writes:

I read about that in SQL3 yesterday and I think we could transparently
adapt the current group scheme to it.

Sorry, I skip this part in my previous letter. Why you mean adaptation
to current group scheme?

I said adapt the current group scheme to roles. The current groups are a
functional subset of what roles do.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sat Mar 4 12:05:29 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA67590
for <pgsql-hackers@postgresql.org>; Sat, 4 Mar 2000 12:04:49 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63515 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S407565AbQCDREE>;
Sat, 4 Mar 2000 18:04:04 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12RI1M-0000Bq-00; Sat, 04 Mar 2000 18:07:16 +0100
Date: Sat, 4 Mar 2000 18:07:16 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: ACL enhancements (was Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE
and NO-LOCK-TABLE)
In-Reply-To: <Pine.LNX.3.96.1000302152527.3304C-100000@ara.zf.jcu.cz>
Message-ID: <Pine.LNX.4.21.0003041437470.352-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

Karel Zak - Zakkr writes:

No. How often you LOCKing table? If you work in transaction block and DB
design is good (or very simple), you not need very often the LOCK.

I agree with providing access restrictions for locking tables in ShareLock
and above, perhaps via a GRANT LOCK ON TABLE command. But just saying
"Don't use LOCK" isn't going to cut it, it must be done throughout *all*
commands that do any locking, otherwise it's just inconsistent.

You have a point that these higher level locks aren't really anybody's
business other than the table owner, superusers, and those explicitly
granted access to them. But saying that you can run your database without
locks is false because even plain UPDATE gets a row exclusive lock.

I a little speculated about it and IHO is real possible make CRATE ROLE,
CREATE PROFILE and global pg_acl table and extend GRANT (function,alter..).
See example Oracle8 documentation (example on: http://mravenec.jcu.cz/oracle),
it is more readable than SQL standards :-)

I don't have any real problems with reading SQL standards. I'd rather do
that than submit to some vendor's ideas. Having said that, I'll still read
the above, especially because profiles are not in SQL.

I have given some more thought to the design of the pg_acl table (which
should not be global if it wants to be SQL compliant). I realize that the
size of my proposed 'one row per user/object/privilege' can grow rather
huge (20 users, 100 tables/things -> probably ca. 5000 rows) but I see
this as the best way some of the things (column access, grant options,
roles) can be implemented in the first place and it will be much easier to
verify the implementation because you can read it right out of SQL.

I think caching can be done pretty effectively, too, since ACL items
rarely change once they're set up. I'm inclined to ask other people's
opinions on this item. Other than that, I think we have a winner
here. Time to bring this up the the rest of the folks and draw up a
project page ...

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sat Mar 4 20:48:35 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA11237
for <pgsql-hackers@postgresql.org>; Sat, 4 Mar 2000 20:47:52 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA11951
for <pgsql-hackers@postgresql.org>; Sun, 5 Mar 2000 10:47:51 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-16 [133.137.84.16])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id KAA08038
for <pgsql-hackers@postgresql.org>; Sun, 5 Mar 2000 10:47:49 +0900
To: pgsql-hackers@postgresql.org
Subject: TransactionStateData and AbsoluteTime
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000305105456Y.t-ishii@sra.co.jp>
Date: Sun, 05 Mar 2000 10:54:56 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 15

Hi, I'm wondering why the transaction star time in
TransactionStateData is Absolutetime. From nabstime.h:

* Although time_t generally is a long int on 64 bit systems, these two
* types must be 4 bytes, because that's what the system assumes. They
* should be yanked (long) before 2038 and be replaced by timestamp and
* interval.
*/
typedef int32 AbsoluteTime;
typedef int32 RelativeTime;

Shouldn't we use timestamp instead of AbsoluteTime in
TransactionStateData? It also gives more precision.
--
Tatsuo Ishii

From bouncefilter Sun Mar 5 04:03:39 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA88724
for <pgsql-hackers@postgresql.org>; Sun, 5 Mar 2000 04:02:46 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id SAA19816
for <pgsql-hackers@postgresql.org>; Sun, 5 Mar 2000 18:02:44 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-4 [133.137.84.4])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id SAA11261
for <pgsql-hackers@postgresql.org>; Sun, 5 Mar 2000 18:02:43 +0900
To: pgsql-hackers@postgresql.org
Subject: DROP TABLE inside a transaction block
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000305180951D.t-ishii@sra.co.jp>
Date: Sun, 05 Mar 2000 18:09:51 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 19

I see following in HISTORY:

Disallow DROP TABLE/DROP INDEX inside a transaction block

However, it seems that this is not done with current?

test=# create table t1(i int);
CREATE
test=# begin;
BEGIN
test=# drop table t1;
NOTICE: Caution: DROP TABLE cannot be rolled back, so don't abort now
DROP
test=# end;
COMMIT
test=# \d
No relations found.
--
Tatsuo Ishii

From bouncefilter Sun Mar 5 04:27:40 2000
Received: from loopy.berkhirt.com (loopy.berkhirt.com [209.220.85.54])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA89776
for <pgsql-hackers@postgreSQL.org>; Sun, 5 Mar 2000 04:27:26 -0500 (EST)
(envelope-from bhirt@loopy.berkhirt.com)
Received: (from bhirt@localhost)
by loopy.berkhirt.com (8.9.3/8.9.3) id DAA30355;
Sun, 5 Mar 2000 03:26:55 -0600
Date: Sun, 5 Mar 2000 03:26:55 -0600
From: Brian Hirt <bhirt@mobygames.com>
To: pgsql-hackers@postgreSQL.org
Cc: Brian Hirt <bhirt@loopy.berkhirt.com>
Subject: Optimizer badness in 7.0 beta
Message-ID: <20000305032655.A29257@loopy.berkhirt.com>
Reply-To: bhirt@mobygames.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1us
X-PC-Gaming: http://www.mobygames.com/

Hello,

I just downloaded the 7.0 beta to test it with my database to make sure
there will be no unexpected problems when I upgrade my production site.
I've run into a problem that I hope you can help me with. I dumped my
6.5.2 database and loaded it into 7.0. Lot's of queries are now taking
much much longer. I have included the plans from one of the queries.
In 7.0, the query takes 94 seconds compared to less than a second for
it to run on 6.5.2. All of the data is exactly the same, the indexes are the
same. I thought maybe the indexes had bad statistics, so I "vaccum analyze"
both the 6.5.2 database and the 7.0 database and ran again on both just to
be on the safe side. Still, same problem. I know that there were problems
with IN clauses optimizing and the preferred method is to use an exists
statement. However, I wouldn't expect this kind of change in performance.
It does appear that 7.0 is trying to be smarter by using an index in the
SubPlan, but for some reason it's being a hog.

Some more information that may be useful, the table 'game' has about 1000
rows and the table game_developer has about 15000 rows. There is an
index on game_developer(developer_id)

Other than these types of queries, everything else seems to be working
okay. I logged about 500 different queries that run against my database,
removed the ones that exhibit the behaviour above and ran a little
benchmark. The run times between 6.5.2 and 7.0.0, for the types of
queries I'm running, are almost identical. I was hoping that the new
improved optimizer would bring a great speed improvement, but I'm not
seeing it. My guess is that most of the queries that I'm running are
small and there's a fixed cost associated with running each one -- the
actual work they perform is pretty small. Possibly more time is being
spent optimizing the plan and is offsetting the improved execution time
on smaller queries.

-brian

-- PG 7.0 --
NOTICE: QUERY PLAN:

Sort (cost=383940.72..383940.72 rows=905 width=59)
-> Seq Scan on game (cost=0.00..383896.28 rows=905 width=59)
SubPlan
-> Unique (cost=0.00..808.88 rows=0 width=4)
-> Index Scan using game_developer_game_index on game_developer (cost=0.00..808.87 rows=4 width=4)

EXPLAIN

-- PG 6.5.2 --
NOTICE: QUERY PLAN:

Sort (cost=99.32 rows=872 width=59)
-> Seq Scan on game (cost=99.32 rows=872 width=59)
SubPlan
-> Unique (cost=578.53 rows=2 width=4)
-> Sort (cost=578.53 rows=2 width=4)
-> Seq Scan on game_developer (cost=578.53 rows=2 width=4)

EXPLAIN

Query:

select
creation_timestamp,
approved,
moby_user_id,
copyright_year,
game_title,
game_url,
company_line,
credits_complete,
game_id
from
game
where
approved = 1
and
game_id in (
select
distinct game_id
from
game_developer
where
developer_id = 3)
order by
copyright_year desc,
game_title;
--
The world's most ambitious and comprehensive PC game database project.

http://www.mobygames.com

From bouncefilter Sun Mar 5 08:27:42 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA08519
for <pgsql-hackers@postgresql.org>; Sun, 5 Mar 2000 08:27:25 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62438 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S333864AbQCEN0d>;
Sun, 5 Mar 2000 14:26:33 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12Rb6V-000076-00
for pgsql-hackers@postgresql.org; Sun, 05 Mar 2000 14:29:51 +0100
Date: Sun, 5 Mar 2000 14:29:50 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: pg_pwd trigger to be removed
Message-ID: <Pine.LNX.4.21.0003051422190.347-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

Because of the problems that were pointed out, I'm inclined to remove the
pg_pwd updating trigger again. I can offer you the non-initdb requiring
variant (just remove the trigger definition in initdb) or the
clean-sweeping one (remove the trigger function from the backend). Okay,
the first one will require some sort of intervention as well, eventually,
but you see the difference.

My new take on the situation is actually that there shouldn't be a reason
to tinker with the systems catalogs period. In the case of pg_shadow
that's not entirely possible (catupd and trace can't be adjusted
otherwise), but that can be fixed (not now). After all they're called
*system* catalogs. If someone thinks they can rename a table by updating
pg_class.relname -- good night!

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sun Mar 5 08:34:42 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA08915
for <pgsql-hackers@postgresql.org>; Sun, 5 Mar 2000 08:33:53 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64254 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S342056AbQCENdH>;
Sun, 5 Mar 2000 14:33:07 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12RbCo-00008i-00; Sun, 05 Mar 2000 14:36:22 +0100
Date: Sun, 5 Mar 2000 14:36:22 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
In-Reply-To: <20000305180951D.t-ishii@sra.co.jp>
Message-ID: <Pine.LNX.4.21.0003051434090.347-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

Tatsuo Ishii writes:

I see following in HISTORY:

Disallow DROP TABLE/DROP INDEX inside a transaction block

However, it seems that this is not done with current?

test=# create table t1(i int);
CREATE
test=# begin;
BEGIN
test=# drop table t1;
NOTICE: Caution: DROP TABLE cannot be rolled back, so don't abort now

Wow, with all due respect, that's pretty sh^H^Hpoor. That's like saying
"Haha, either you commit your transaction or your database is fried." Any
reason that's not an ERROR before anything destructive is done?

DROP
test=# end;
COMMIT
test=# \d
No relations found.
--
Tatsuo Ishii

************

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sun Mar 5 08:37:42 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA09122
for <pgsql-hackers@postgresql.org>; Sun, 5 Mar 2000 08:37:13 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63643 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S327720AbQCENgU>;
Sun, 5 Mar 2000 14:36:20 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12RbFx-00008k-00; Sun, 05 Mar 2000 14:39:37 +0100
Date: Sun, 5 Mar 2000 14:39:37 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] TransactionStateData and AbsoluteTime
In-Reply-To: <20000305105456Y.t-ishii@sra.co.jp>
Message-ID: <Pine.LNX.4.21.0003051436470.347-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

Tatsuo Ishii writes:

Shouldn't we use timestamp instead of AbsoluteTime in
TransactionStateData? It also gives more precision.

Thomas was hesitant to using 8 byte types internally across the board. He
must have his reasons.

I think that eventually *all* time'ish stuff should be moved to the new
stuff but perhaps we should wait until the current datetime-related panic
has died down. :)

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sun Mar 5 09:13:46 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA11022
for <pgsql-hackers@postgresql.org>; Sun, 5 Mar 2000 09:13:17 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64930 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S389160AbQCEOMb>;
Sun, 5 Mar 2000 15:12:31 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12Rbov-0000AU-00; Sun, 05 Mar 2000 15:15:45 +0100
Date: Sun, 5 Mar 2000 15:15:45 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Brian Hirt <bhirt@mobygames.com>
cc: pgsql-hackers@postgresql.org, Brian Hirt <bhirt@loopy.berkhirt.com>
Subject: Re: [HACKERS] Optimizer badness in 7.0 beta
In-Reply-To: <20000305032655.A29257@loopy.berkhirt.com>
Message-ID: <Pine.LNX.4.21.0003051506410.347-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

This query can be rewritten as

SELECT creation_timestamp, etc.
FROM game, game_developer
WHERE game.game_id = game_developer.game_id
AND approved = 1 AND developer_id = 3
ORDER BY copyright_year desc, game_title

The way you're writing it you're almost asking it to be slow. :)

Of course that still doesn't explain why it's now 94sec versus formerly 1
but I'm sure Tom Lane will enlighten us all very soon. :)

Brian Hirt writes:

select
creation_timestamp,

[snip]

from
game
where
approved = 1
and
game_id in (
select
distinct game_id
from
game_developer
where
developer_id = 3)
order by
copyright_year desc,
game_title;

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sun Mar 5 16:02:47 2000
Received: from loopy.berkhirt.com (loopy.berkhirt.com [209.220.85.54])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA99918
for <pgsql-hackers@postgreSQL.org>; Sun, 5 Mar 2000 16:02:24 -0500 (EST)
(envelope-from bhirt@loopy.berkhirt.com)
Received: (from bhirt@localhost)
by loopy.berkhirt.com (8.9.3/8.9.3) id PAA10933;
Sun, 5 Mar 2000 15:01:32 -0600
Date: Sun, 5 Mar 2000 15:01:32 -0600
From: Brian Hirt <bhirt@mobygames.com>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Optimizer badness in 7.0 beta
Message-ID: <20000305150132.B29257@loopy.berkhirt.com>
Reply-To: bhirt@mobygames.com
References: <20000305032655.A29257@loopy.berkhirt.com>
<Pine.LNX.4.21.0003051506410.347-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 1.0.1us
In-Reply-To: <Pine.LNX.4.21.0003051506410.347-100000@localhost.localdomain>;
from peter_e@gmx.net on Sun, Mar 05, 2000 at 03:15:45PM +0100
X-PC-Gaming: http://www.mobygames.com/

Peter,

Actually, the query you supply will not work, I'll get duplicate
rows because the relationship between game and game_developer is
a one to many. Of course you had no way of knowing that from the
information I supplied. I could throw a distinct in there to get
the results, but that really feels like bad form because of the large
amount of duplicate rows. In any case, the original query I supplied
is generated SQL, created by a Database to Object persistance layer
and cannot by design have multiple tables in the from clause, so
restrictions to the table seleted from must be in the form of a
qualifier.

I realize that the query in question could be written better. My
concern was the huge difference in performance between 6.5 and 7.0 on
this type of query. Other people may be bitten by this one, so I wanted
to bring it up. I've been able to easily to work around this problem,
it just seems wrong that the difference in execution time is so far
off from the previous release.

I dont know too much about the PG internals, but when I used sybase,
it would usually execute the sub-select independently and stuff the
results into a temp table and then do another query, joining to the
results of the sub-select. In a situation like this one, worst case
without indexes you would get a table scan for the sub-select
and then a merge join with a sequential scan on the temp table and a
sequential scan on the other table (example below). Using that
approach, with no indexes, the query still executes in a fraction of a
second. It just seems that a query on tables as small as I'm describing
should never take as long as it did. It seems like a problem with
the optimizer, but if people are happy with currenty functionality that's
fine with me also.

-brian

For Example:

SELECT DISTINCT game_id INTO temp tmp_res
FROM game_developer
WHERE developer_id = 3

SELECT *
FROM game, tmp_res
WHERE game.game_id = tmp_res.game_id
AND game.approved = 1
ORDER BY copyright_year desc, game_title

On Sun, Mar 05, 2000 at 03:15:45PM +0100, Peter Eisentraut wrote:

This query can be rewritten as

SELECT creation_timestamp, etc.
FROM game, game_developer
WHERE game.game_id = game_developer.game_id
AND approved = 1 AND developer_id = 3
ORDER BY copyright_year desc, game_title

The way you're writing it you're almost asking it to be slow. :)

Of course that still doesn't explain why it's now 94sec versus formerly 1
but I'm sure Tom Lane will enlighten us all very soon. :)

Brian Hirt writes:

select
creation_timestamp,

[snip]

from
game
where
approved = 1
and
game_id in (
select
distinct game_id
from
game_developer
where
developer_id = 3)
order by
copyright_year desc,
game_title;

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

************

--
The world's most ambitious and comprehensive PC game database project.

http://www.mobygames.com

From bouncefilter Sun Mar 5 20:34:51 2000
Received: from corvette.mascari.com (dhcp26136016.columbus.rr.com
[24.26.136.16]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA27155
for <pgsql-hackers@postgreSQL.org>; Sun, 5 Mar 2000 20:34:27 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id UAA23570;
Sun, 5 Mar 2000 20:31:24 -0500
Message-ID: <38C30A6D.FC8D2AD9@mascari.com>
Date: Sun, 05 Mar 2000 20:31:25 -0500
From: Mike Mascari <mascarm@mascari.com>
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
References: <Pine.LNX.4.21.0003051434090.347-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Eisentraut wrote:

Tatsuo Ishii writes:

I see following in HISTORY:

Disallow DROP TABLE/DROP INDEX inside a transaction block

However, it seems that this is not done with current?

test=# create table t1(i int);
CREATE
test=# begin;
BEGIN
test=# drop table t1;
NOTICE: Caution: DROP TABLE cannot be rolled back, so don't abort now

Wow, with all due respect, that's pretty sh^H^Hpoor. That's like saying
"Haha, either you commit your transaction or your database is fried." Any
reason that's not an ERROR before anything destructive is done?

DROP
test=# end;
COMMIT
test=# \d
No relations found.

We had an elaborate discussion on this very topic several months
ago. What it comes down to is three possible options:

1) Allow DDL statements in transactions. If the transaction
aborts, currently, corruption can result. Some DDL statements
(such as TRUNCATE) make no sense with respect to ROLLBACK. So, I
guess, the idea is that SOME DDL statements will be ROLLBACK-able
and some won't - yuck.

2) Disallow DDL statement in transactions. This would break code
for people which is working now, only because their transactions
are being committed between the time they issue the DDL statement
and the COMMIT (or END), instead of aborting and causing their
database to become corrupt, or require manual removal of files
when the catalogue gets out-of-sync with the filesystem.

3) Implicitly commit the running transaction and begin a new one.
Only Vadim and I support this notion, although this is precisely
what Oracle does (not that that should define PostgreSQL's
behavior, of course). Everyone else, it seems wants to try to
implement #1 successfully...(I don't see it happening any time
soon).

So, as some sort of compromise, a NOTICE was issued.

Mike Mascari

From bouncefilter Mon Mar 6 03:06:55 2000
Received: from corvette.mascari.com (dhcp26136016.columbus.rr.com
[24.26.136.16]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA79554
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Mar 2000 03:06:41 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id DAA24377;
Mon, 6 Mar 2000 03:03:25 -0500
Sender: mascarm@corvette.mascari.com
Message-ID: <38C32000.473F893A@mascari.com>
Date: Sun, 05 Mar 2000 22:03:28 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Philip Warner <pjw@rhyme.com.au>
CC: Peter Eisentraut <peter_e@gmx.net>, Tatsuo Ishii <t-ishii@sra.co.jp>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
References: <38C30A6D.FC8D2AD9@mascari.com>
<3.0.5.32.20000306182734.01ec7100@mail.rhyme.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Philip Warner wrote:

At 07:59 6/03/00 +0100, Peter Eisentraut wrote:

(such as TRUNCATE) make no sense with respect to ROLLBACK. So, I
guess, the idea is that SOME DDL statements will be ROLLBACK-able
and some won't - yuck.

I don't see a problem with disallowing some DDL commands in a transaction
as long as they throw an error and the transaction aborts.

Is it really necessary to abort the TX? Seems a little antisocial - can't
you just return an error, and let the user/application decide if it needs
to abort?

3) Implicitly commit the running transaction and begin a new one.
Only Vadim and I support this notion, although this is precisely
what Oracle does (not that that should define PostgreSQL's
behavior, of course). Everyone else, it seems wants to try to
implement #1 successfully...(I don't see it happening any time
soon).

I support that too since it also happens to be SQL's idea more or less.
One of these days we'll have to offer this as an option. At least for
commands for which #1 doesn't work yet.

Do you really mean it when ou say 'Implicitly commit the running
transaction'. I would be deeply opposed to this philosophically, if so. No
TX should ever be commited unless the user requests it.

Just my 0.02c

Philosophically, I agree with you 100%. And apparently, from the
previous discussion on this issue, databases like Informix are
completely capable of rolling back DDL statements like DROP
TABLE, ALTER TABLE RENAME, etc. However, the complexity involved
apparently was too much for Oracle:

"ORACLE implicitly commits the current transaction before and
after every Data Definition Language statement."

Its just my feeling that robustness is the number one priority
and that the current state is kind of "riding the fence" between
ORACLE and Informix. On either side of the fence, it is safe, but
in the middle, you risk corruption.

Naturally, I'd like to see PostgreSQL on the Informix side of the
fence, but I don't see it happening any time soon. And the ORACLE
side of the fence is far easier to implement. Or, of course, you
could choose Peter's suggestion, and disallow the DDL statement
entirely. But as soon as that happened, all those people that
begin their .cgi programs with BEGIN and end it with END will
say, "Hey, if we can't use DDL statements in transactions, can't
we at least do what Oracle does so we don't have to change our
code?"

Mike Mascari

From bouncefilter Mon Mar 6 05:47:59 2000
Received: from corvette.mascari.com (dhcp26136016.columbus.rr.com
[24.26.136.16]) by hub.org (8.9.3/8.9.3) with ESMTP id FAA22719
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Mar 2000 05:47:21 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id FAA24579;
Mon, 6 Mar 2000 05:44:35 -0500
Sender: mascarm@corvette.mascari.com
Message-ID: <38C345C7.1F2EDAA7@mascari.com>
Date: Mon, 06 Mar 2000 00:44:39 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>,
"'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: AW: [HACKERS] DROP TABLE inside a transaction block
References: <Pine.GSO.4.02A.10003061104500.19000-100000@Svan.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Eisentraut wrote:

On Mon, 6 Mar 2000, Zeugswetter Andreas SB wrote:

Yes, that was also the general consensus on the list. No statement is
ever going to do an implicit commit of previous statements.

I can understand that, but one of these days I hope we can offer the SQL
semantics of transactions where you don't require a BEGIN. (*Optional*,
people.)

I often think that the current behavior with respect to BEGIN
often hurts PostgreSQL's reputation with respect to speed. If the
default behavior was to begin a transaction at the first
non-SELECT DML statement, PostgreSQL wouldn't fare so poorly in
tests of:

INSERT INTO testspeed(1);
INSERT INTO testspeed(2);
INSERT INTO testspeed(3);
...
INSERT INTO testspeed(100000);

where, the same .sql script submitted against other databases is
running in a transaction, and, as such, is not being committed
immediately to disk. Fortunately, the Ziff-Davis reviewer ran his
tests with fsync() off. But your run-of-the-mill enterprise
application developer is probably going to just install the
software via rpms and run their sql scripts against it.

In that case you have to do *something* about non-rollbackable
DDL (face it, there's always going to be one). Doing what Oracle does is
certainly not the *worst* one could do. Again, optional.

That still doesn't excuse the current behavior though.

I can certainly understand Andreas' viewpoint. If no DDL,
however, was allowed inside a transaction -or- you could
optionally turn on implicit commit, imagine how much easier life
becomes in implementing ALTER TABLE DROP COLUMN, DROP TABLE, DROP
INDEX, etc, not having to worry about restoring filesystem files,
or deleting them in aborted CREATE TABLE/CREATE INDEX statements,
etc. A far-reaching idea would be to make use of foreign keys in
the system catalogue, with triggers used to add/rename/remove
relation files. That could be done if DDL statements could not be
executed in transactions. With AccessExclusive locks on the
appropriate relations, a host of race-condition related bugs
would disappear. And the complexity involved with dropping (or
perhaps disallowing the dropping of) related objects, such as
triggers, indexes, etc. would be automatic.

Mike Mascari

From bouncefilter Mon Mar 6 01:07:54 2000
Received: from rotec.sibnet.ru (IDENT:root@rotec-gw.sibnet.ru
[194.84.102.185])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA47732
for <pgsql-hackers@postgresql.org>; Mon, 6 Mar 2000 01:06:50 -0500 (EST)
(envelope-from A.S.Zakharov@inp.nsk.su)
Received: from magic (magic.rotec.sibnet.ru [10.1.1.1])
by rotec.sibnet.ru (8.9.3/8.9.3) with SMTP id OAA04236
for <pgsql-hackers@postgresql.org>; Mon, 6 Mar 2000 14:22:28 +0600
Message-ID: <003001bf8732$1c3df400$0101010a@magic>
From: "Alexei Zakharov" <A.S.Zakharov@inp.nsk.su>
To: "PostgreSQL Development" <pgsql-hackers@postgresql.org>
Subject: xlog.c.patch for cygwin port.
Date: Mon, 6 Mar 2000 12:06:27 +0600
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_002C_01BF8764.66AF0A10"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

This is a multi-part message in MIME format.

------=_NextPart_000_002C_01BF8764.66AF0A10
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_002D_01BF8764.66AF0A10"

------=_NextPart_001_002D_01BF8764.66AF0A10
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hello,

I've recently written to pgsql-ports about a problem with PG7.0 on NT =
(Subj: [PORTS] initdb problem on NT with 7.0). Since nobody helped me, =
I had to find out the reson. The difference between NT and Linux (for =
instance) is that "open( path, O_RDWR );" opens a file in text mode. So =
sometime less block can be read than required.

I suggest a following patch. BTW the situation appeared before, see =
hba.c, pqcomm.c and others.

------=_NextPart_001_002D_01BF8764.66AF0A10
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hello,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>I've recently written to pgsql-ports about a problem =
with=20
PG7.0 on NT (Subj: [PORTS] initdb problem on NT with =
7.0).&nbsp;&nbsp;Since=20
nobody helped me, I had to find out the reson.&nbsp; The difference =
between NT=20
and Linux (for instance) is that "open( path, O_RDWR );" opens a file in =
text=20
mode.&nbsp; So sometime less block can be read than =
required.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>I suggest a following patch.&nbsp; BTW the situation =
appeared=20
before, see hba.c, pqcomm.c and others.</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_001_002D_01BF8764.66AF0A10--

------=_NextPart_000_002C_01BF8764.66AF0A10
Content-Type: application/octet-stream;
name="xlog.c.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="xlog.c.patch"

*** xlog.c.orig	Tue Feb 15 14:00:12 2000
--- xlog.c	Mon Mar 06 12:59:40 2000
***************
*** 726,732 ****
--- 726,736 ----
  	unlink(path);
 =20
  tryAgain:
+ #ifndef __CYGWIN__
  	fd =3D open(path, O_RDWR|O_CREAT|O_EXCL, S_IRUSR|S_IWUSR);
+ #else
+ 	fd =3D open(path, O_RDWR|O_CREAT|O_EXCL|O_BINARY, S_IRUSR|S_IWUSR);
+ #endif
  	if (fd < 0 && (errno =3D=3D EMFILE || errno =3D=3D ENFILE))
  	{
  		fd =3D errno;
***************
*** 767,773 ****
--- 771,781 ----
  	XLogFileName(path, log, seg);
 =20
  tryAgain:
+ #ifndef __CYGWIN__
  	fd =3D open(path, O_RDWR);
+ #else
+ 	fd =3D open(path, O_RDWR | O_BINARY);
+ #endif
  	if (fd < 0 && (errno =3D=3D EMFILE || errno =3D=3D ENFILE))
  	{
  		fd =3D errno;
***************
*** 1083,1089 ****
--- 1091,1101 ----
  	int		fd;
 =20
  tryAgain:
+ #ifndef __CYGWIN__
  	fd =3D open(ControlFilePath, O_RDWR);
+ #else
+ 	fd =3D open(ControlFilePath, O_RDWR | O_BINARY);
+ #endif
  	if (fd < 0 && (errno =3D=3D EMFILE || errno =3D=3D ENFILE))
  	{
  		fd =3D errno;
***************
*** 1145,1151 ****
--- 1157,1167 ----
  	CheckPoint		checkPoint;
  	XLogRecord	   *record;
 =20
+ #ifndef __CYGWIN__
  	fd =3D open(ControlFilePath, O_RDWR|O_CREAT|O_EXCL, S_IRUSR|S_IWUSR);
+ #else
+ 	fd =3D open(ControlFilePath, O_RDWR|O_CREAT|O_EXCL|O_BINARY, =
S_IRUSR|S_IWUSR);
+ #endif
  	if (fd < 0)
  		elog(STOP, "BootStrapXLOG failed to create control file (%s): %d",=20
  					ControlFilePath, errno);
***************
*** 1249,1255 ****
--- 1265,1275 ----
  	 * Open/read Control file
  	 */
  tryAgain:
+ #ifndef __CYGWIN__
  	fd =3D open(ControlFilePath, O_RDWR);
+ #else
+ 	fd =3D open(ControlFilePath, O_RDWR | O_BINARY);
+ #endif
  	if (fd < 0 && (errno =3D=3D EMFILE || errno =3D=3D ENFILE))
  	{
  		fd =3D errno;

------=_NextPart_000_002C_01BF8764.66AF0A10--

From bouncefilter Mon Mar 6 01:59:55 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA51447
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Mar 2000 01:59:05 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Svan.DoCS.UU.SE (e99re41@Svan.DoCS.UU.SE [130.238.9.160])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id HAA09878;
Mon, 6 Mar 2000 07:59:01 +0100 (MET)
Received: from localhost (e99re41@localhost) by Svan.DoCS.UU.SE
(8.6.12/8.6.12) with ESMTP id HAA17643;
Mon, 6 Mar 2000 07:59:00 +0100
X-Authentication-Warning: Svan.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 6 Mar 2000 07:59:00 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Mike Mascari <mascarm@mascari.com>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
In-Reply-To: <38C30A6D.FC8D2AD9@mascari.com>
Message-ID: <Pine.GSO.4.02A.10003060754300.17581-100000@Svan.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.org id BAA54326

On Sun, 5 Mar 2000, Mike Mascari wrote:

1) Allow DDL statements in transactions. If the transaction
aborts, currently, corruption can result. Some DDL statements

^^^^^^^^^^^^^^^^^^^^^
I think those are the key words.

(such as TRUNCATE) make no sense with respect to ROLLBACK. So, I
guess, the idea is that SOME DDL statements will be ROLLBACK-able
and some won't - yuck.

I don't see a problem with disallowing some DDL commands in a transaction
as long as they throw an error and the transaction aborts. Users see this
and don't do it next time. Sure it's inconsistent but the current state is
plain bad, sorry.

3) Implicitly commit the running transaction and begin a new one.
Only Vadim and I support this notion, although this is precisely
what Oracle does (not that that should define PostgreSQL's
behavior, of course). Everyone else, it seems wants to try to
implement #1 successfully...(I don't see it happening any time
soon).

I support that too since it also happens to be SQL's idea more or less.
One of these days we'll have to offer this as an option. At least for
commands for which #1 doesn't work yet.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Mar 6 02:07:06 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA69031
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Mar 2000 02:05:58 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Svan.DoCS.UU.SE (e99re41@Svan.DoCS.UU.SE [130.238.9.160])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id IAA09966;
Mon, 6 Mar 2000 08:05:53 +0100 (MET)
Received: from localhost (e99re41@localhost) by Svan.DoCS.UU.SE
(8.6.12/8.6.12) with ESMTP id IAA17671;
Mon, 6 Mar 2000 08:05:52 +0100
X-Authentication-Warning: Svan.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 6 Mar 2000 08:05:52 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Brian Hirt <bhirt@mobygames.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Optimizer badness in 7.0 beta
In-Reply-To: <20000305150132.B29257@loopy.berkhirt.com>
Message-ID: <Pine.GSO.4.02A.10003060759180.17581-100000@Svan.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.org id CAA69125

On Sun, 5 Mar 2000, Brian Hirt wrote:

Actually, the query you supply will not work, I'll get duplicate
rows because the relationship between game and game_developer is
a one to many.

Got me. I tried to read into it a little like 'one developer develops many
games' but apparently it's the other way around. In that case you could
use DISTINCT or maybe DISTINCT ON depending on the details.

I dont know too much about the PG internals, but when I used sybase,
it would usually execute the sub-select independently and stuff the
results into a temp table and then do another query, joining to the
results of the sub-select.

Last time I checked PostgreSQL executes the subquery for each row.
Apparently it must still be doing that and I do suspect that it is right
in the overall sense because the subquery may have side effects. Consider

SELECT * FROM t1 WHERE id IN (select nextval('my_sequence'))

Of course this query makes absolutely no sense whatsoever but perhaps
there are similar ones where it does.

But I didn't mean to bash your query style, just pointing out a
work-around that's commonly suggested. (People have been caught by this
before.)

SELECT creation_timestamp, etc.

^^ insert DISTINCT

FROM game, game_developer
WHERE game.game_id = game_developer.game_id
AND approved = 1 AND developer_id = 3
ORDER BY copyright_year desc, game_title

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Mar 6 02:28:54 2000
Received: from acheron.rime.com.au (root@albatr.lnk.telstra.net
[139.130.54.222]) by hub.org (8.9.3/8.9.3) with ESMTP id CAA72190
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Mar 2000 02:28:04 -0500 (EST)
(envelope-from pjw@rhyme.com.au)
Received: from oberon (Oberon.rime.com.au [203.8.195.100])
by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id SAA20627;
Mon, 6 Mar 2000 18:26:58 +1100
Message-Id: <3.0.5.32.20000306182734.01ec7100@mail.rhyme.com.au>
X-Sender: pjw@mail.rhyme.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 06 Mar 2000 18:27:34 +1100
To: Peter Eisentraut <peter_e@gmx.net>, Mike Mascari <mascarm@mascari.com>
From: Philip Warner <pjw@rhyme.com.au>
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
Cc: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
In-Reply-To: <Pine.GSO.4.02A.10003060754300.17581-100000@Svan.DoCS.UU.SE

References: <38C30A6D.FC8D2AD9@mascari.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 07:59 6/03/00 +0100, Peter Eisentraut wrote:

(such as TRUNCATE) make no sense with respect to ROLLBACK. So, I
guess, the idea is that SOME DDL statements will be ROLLBACK-able
and some won't - yuck.

I don't see a problem with disallowing some DDL commands in a transaction
as long as they throw an error and the transaction aborts.

Is it really necessary to abort the TX? Seems a little antisocial - can't
you just return an error, and let the user/application decide if it needs
to abort?

3) Implicitly commit the running transaction and begin a new one.
Only Vadim and I support this notion, although this is precisely
what Oracle does (not that that should define PostgreSQL's
behavior, of course). Everyone else, it seems wants to try to
implement #1 successfully...(I don't see it happening any time
soon).

I support that too since it also happens to be SQL's idea more or less.
One of these days we'll have to offer this as an option. At least for
commands for which #1 doesn't work yet.

Do you really mean it when ou say 'Implicitly commit the running
transaction'. I would be deeply opposed to this philosophically, if so. No
TX should ever be commited unless the user requests it.

Just my 0.02c

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

From bouncefilter Mon Mar 6 03:31:55 2000
Received: from gandalf.it-austria.net (gandalf.it-austria.net [213.150.1.65])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA03373
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Mar 2000 03:31:53 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at (sdgtw.sd.spardat.at
[172.18.1.16])
by gandalf.it-austria.net (xxx/xxx) with ESMTP id JAA98530
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Mar 2000 09:31:36 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <1TSZH4PH>; Mon, 6 Mar 2000 09:31:36 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C604AF7D0B@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] DROP TABLE inside a transaction block
Date: Mon, 6 Mar 2000 09:31:30 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

3) Implicitly commit the running transaction and begin a new one.
Only Vadim and I support this notion, although this is precisely
what Oracle does (not that that should define PostgreSQL's
behavior, of course). Everyone else, it seems wants to try to
implement #1 successfully...(I don't see it happening any time
soon).

I support that too since it also happens to be SQL's idea more or less.
One of these days we'll have to offer this as an option. At least for
commands for which #1 doesn't work yet.

Do you really mean it when ou say 'Implicitly commit the running
transaction'. I would be deeply opposed to this philosophically, if so. No
TX should ever be commited unless the user requests it.

Yes, that was also the general consensus on the list.
No statement is ever going to do an implicit commit of
previous statements.

Andreas

Peter, thanks for your support !

I'm surprised this bug isn't taken seriously by other people.

about the fact that this isn't considered as a bug fix, I disagree
entirely: it's a fix to an important security issue.

It adds nothing. The only thing it changes is "du" instead of "w" in the
acls, so people would have to dump and restore their databases when
upgrading to a fixed version, but that's probably already the case for
upgrading from 6.5x to 7.x (I don't know). Of course I agree that this fix
needs a lot more testing than most bug fixes, and I haven't tested all the
possibilities (particularly with sequences, which I have not tested at
all).

I'm even more surprised this wasn't noticed before, or do all users deal
with databases as superuser ? For those of you who have any doubt, I
suggest you look at a recent thread on BUGTRAQ (find it on
http://www.securityfocus.com) to know what problems this bug can generate
if used by bad people.

I've even received a mail trying to explain me that update and delete are
the same thing because you can update a record you want to delete but have
no right to, to change its data... of course this is possible, but
nevertheless the record isn't deleted, so update and delete really are two
different things, not to mention you may want to give delete permission
but not insert nor update.

As I told previously in private to Bruce, I won't be able to make this
patch for 7.0 until a week or two, so if someone do it before (please do,
because you better know postgresql code than me, so you'll make less
mistakes), just tell me because I don't really want to duplicate the
effort.

bye,

PS: could someone explain me what "tricky" means ?

Jerome ALET - alet@unice.fr - http://cortex.unice.fr/~jerome
Faculte de Medecine de Nice - http://noe.unice.fr - Tel: 04 93 37 76 30
28 Avenue de Valombrose - 06107 NICE Cedex 2 - FRANCE

On Sat, 4 Mar 2000, Peter Eisentraut wrote:

Bruce Momjian writes:

Looks very nice, but we can't apply it during beta. Only bug fixes, and
this looks a little tricky. We can try it for 7.1. Maybe you can get
us a 7.0 based patch.

It was me that encouraged him to send in this patch now because Karel and
I are currently talking about redoing the ACL stuff for 7.1.

I considered this a bug and the fix looks pretty straightforward. Perhaps
it should go into 7.0.1?

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Mar 6 05:08:56 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA19468
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Mar 2000 05:08:09 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Svan.DoCS.UU.SE (e99re41@Svan.DoCS.UU.SE [130.238.9.160])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id LAA20719;
Mon, 6 Mar 2000 11:08:05 +0100 (MET)
Received: from localhost (e99re41@localhost) by Svan.DoCS.UU.SE
(8.6.12/8.6.12) with ESMTP id LAA19065;
Mon, 6 Mar 2000 11:08:04 +0100
X-Authentication-Warning: Svan.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 6 Mar 2000 11:08:04 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: AW: [HACKERS] DROP TABLE inside a transaction block
In-Reply-To:
<219F68D65015D011A8E000006F8590C604AF7D0B@sdexcsrv1.f000.d0188.sd.spardat.at>
Message-ID: <Pine.GSO.4.02A.10003061104500.19000-100000@Svan.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.org id FAA19510

On Mon, 6 Mar 2000, Zeugswetter Andreas SB wrote:

Yes, that was also the general consensus on the list. No statement is
ever going to do an implicit commit of previous statements.

I can understand that, but one of these days I hope we can offer the SQL
semantics of transactions where you don't require a BEGIN. (*Optional*,
people.) In that case you have to do *something* about non-rollbackable
DDL (face it, there's always going to be one). Doing what Oracle does is
certainly not the *worst* one could do. Again, optional.

That still doesn't excuse the current behavior though.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Mar 6 05:11:57 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA19659
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Mar 2000 05:11:00 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Svan.DoCS.UU.SE (e99re41@Svan.DoCS.UU.SE [130.238.9.160])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id LAA20950;
Mon, 6 Mar 2000 11:10:54 +0100 (MET)
Received: from localhost (e99re41@localhost) by Svan.DoCS.UU.SE
(8.6.12/8.6.12) with ESMTP id LAA19089;
Mon, 6 Mar 2000 11:10:54 +0100
X-Authentication-Warning: Svan.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 6 Mar 2000 11:10:54 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Philip Warner <pjw@rhyme.com.au>
cc: Mike Mascari <mascarm@mascari.com>, Tatsuo Ishii <t-ishii@sra.co.jp>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
In-Reply-To: <3.0.5.32.20000306182734.01ec7100@mail.rhyme.com.au>
Message-ID: <Pine.GSO.4.02A.10003061108220.19000-100000@Svan.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.org id FAA19699

On Mon, 6 Mar 2000, Philip Warner wrote:

I don't see a problem with disallowing some DDL commands in a transaction
as long as they throw an error and the transaction aborts.

Is it really necessary to abort the TX? Seems a little antisocial - can't
you just return an error, and let the user/application decide if it needs
to abort?

I'm afraid yes, it is necessary. Either the whole transaction or none of
it. Anything else is opening a can of worms that you can't control unless
you have a Ph.D. in fancy databases or something. (Incidentally, I know
that a non-zero amount of people around here have one of those, but that
won't help the rest of us much. :{ )

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Mar 6 05:28:56 2000
Received: from gandalf.it-austria.net (gandalf.it-austria.net [213.150.1.65])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA20981
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Mar 2000 05:28:02 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at (sdgtw.sd.spardat.at
[172.18.1.16])
by gandalf.it-austria.net (xxx/xxx) with ESMTP id LAA173880;
Mon, 6 Mar 2000 11:27:50 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <1TSZHVRG>; Mon, 6 Mar 2000 11:27:49 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C604AF7D0D@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Peter Eisentraut'" <peter_e@gmx.net>
Cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: AW: [HACKERS] DROP TABLE inside a transaction block
Date: Mon, 6 Mar 2000 11:27:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Yes, that was also the general consensus on the list. No statement is
ever going to do an implicit commit of previous statements.

I can understand that, but one of these days I hope we can offer the SQL
semantics of transactions where you don't require a BEGIN.
(*Optional*,people.) In that case you have to do *something* about
non-rollbackable DDL (face it, there's always going to be one). Doing what

Oracle does is certainly not the *worst* one could do. Again, optional.

Imho it *is* the worst one can do.
The only also bad, but acceptable solutions to me would be:

1. disallow this DDL if there is any open DML in this tx,
( allow it, if only select or DDL statements since tx open, and do
the implicit commit)
2. handle this DDL outside any transaction scope even if a tx is open

Implicitly committing previous DML with a DDL statement is imho out of
discussion.

Not in the scope of this discussion is imho the "truncate" command,
since it is 1. not SQL92, 2. per definition a non rollbackable statement
and 3. probably rather a DML statement.

That still doesn't excuse the current behavior though.

Agreed

Andreas

From bouncefilter Mon Mar 6 08:48:01 2000
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA32904
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Mar 2000 08:47:42 -0500 (EST)
(envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA26424;
Mon, 6 Mar 2000 14:47:36 +0100
Date: Mon, 6 Mar 2000 14:47:36 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Peter Eisentraut <peter_e@gmx.net>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: ACL enhancements
In-Reply-To: <Pine.LNX.4.21.0003041437470.352-100000@localhost.localdomain>
Message-ID: <Pine.LNX.3.96.1000306132215.14444A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 4 Mar 2000, Peter Eisentraut wrote:

Karel Zak - Zakkr writes:

I have given some more thought to the design of the pg_acl table (which
should not be global if it wants to be SQL compliant). I realize that the
size of my proposed 'one row per user/object/privilege' can grow rather
huge (20 users, 100 tables/things -> probably ca. 5000 rows) but I see
this as the best way some of the things (column access, grant options,
roles) can be implemented in the first place and it will be much easier to
verify the implementation because you can read it right out of SQL.

It must be fast! It is watchword for this project. The ACL is checked
for each query. I agree with one global pg_acl for one DB.

I think caching can be done pretty effectively, too, since ACL items
rarely change once they're set up. I'm inclined to ask other people's

Yes. IMHO will good initialize more user's information after connection start.
Now is init only username, but we can save to any persistent struct full
user's pg_shadow row. (My bash (shell) not see the /etc/password before
each command, it is initialize after bash start and it is persistent to
its end.) The current code look at pg_shadow very often...etc.

opinions on this item. Other than that, I think we have a winner
here. Time to bring this up the the rest of the folks and draw up a
project page ...

Agree. ...a project page with more details, implementation steps ..etc.

Karel

From bouncefilter Mon Mar 6 10:58:00 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA46191
for <pgsql-hackers@postgresql.org>; Mon, 6 Mar 2000 10:57:24 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61098 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S413707AbQCFP4h>;
Mon, 6 Mar 2000 16:56:37 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12RzvJ-0000FJ-00
for pgsql-hackers@postgresql.org; Mon, 06 Mar 2000 16:59:57 +0100
Date: Mon, 6 Mar 2000 16:59:57 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Proposal for Grand Unified Configuration scheme
Message-ID: <Pine.LNX.4.21.0003061512190.362-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

I have (almost) nothing to do for about 3 weeks, so I thought I'd get
started on some stuff for next time around.

The idea here is to unify all the various configuration settings into one
coherent scheme. This would include:

* pg_options
* pg_geqo
* postmaster.opts
* Most of the postgres and postmaster command line options
* (almost?) everything you can use SET on
* All the temporary solutions via server side environment variables

The idea would be an obvious (IMO) extension of what's done in
commands/variable.c: Every conceivable option is assigned a name similar
to an SQL identifier. With that name you could (under this proposal):

1) Do SET "foo" TO 'bar' as usual

2) Pass a default value to the backend via some generic option, say
-@ foo=bar

3) Do the same via the PGOPTIONS variant from the client side

4) Provide a global default via an entry in a configuration file, say
pg_config, of the form foo=bar.

Of course the current and in general the popular options will also retain
their one letter switch in the backend.

In addition it would be nice to include some (better all) of the static
postmaster options (of the -p and -N variety) in the scheme. In that case
only (4) above will apply, of course.

What does this all accomplish you ask? Well, first of all it provides a
framework for making configuration options available via a variety of
channels in a consistent fashion. Secondly, it provides a framework for
easily adding options in the first place. No more, "should this be a
configure option?" (because it most likely should not be a configure
option :). Finally, it gives people something to do when they should be
"administering" their database server. ;)

Let me know what you think. Don't be rushed if you have other things to do
right now.

A somewhat related but more difficult and controversial project would be
to unify the options between postmaster and postgres and revise some of
the old mechanisms from the time when they were separate executables. For
example it would be nice if I could start the postmaster with the -F
option and it would look that up in the grand unified options table (see
above) and say "ah, that's a per-backend option" and pass it on to the
backend. In the above framework this wouldn't be too difficult to do, but
there are conflicting option letters between the two. Of course what
*really* ought to happen is to give up that postgres/postmaster naming
dichotomy as such, but that's another day ...

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Mar 6 13:39:06 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA67651
for <pgsql-hackers@postgresql.org>; Mon, 6 Mar 2000 13:38:37 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12S2Od-000LELC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Mon, 6 Mar 2000 12:38:23 -0600 (CST)
Date: Mon, 6 Mar 2000 12:38:23 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
Cc: Peter Eisentraut <peter_e@gmx.net>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: ACL enhancements
Message-ID: <20000306123823.A28266@rice.edu>
References: <Pine.LNX.4.21.0003041437470.352-100000@localhost.localdomain>
<Pine.LNX.3.96.1000306132215.14444A-100000@ara.zf.jcu.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <Pine.LNX.3.96.1000306132215.14444A-100000@ara.zf.jcu.cz>;
from zakkr@zf.jcu.cz on Mon, Mar 06, 2000 at 02:47:36PM +0100

On Mon, Mar 06, 2000 at 02:47:36PM +0100, Karel Zak - Zakkr wrote:

On Sat, 4 Mar 2000, Peter Eisentraut wrote:

Karel Zak - Zakkr writes:

I have given some more thought to the design of the pg_acl table (which
should not be global if it wants to be SQL compliant). I realize that the
size of my proposed 'one row per user/object/privilege' can grow rather
huge (20 users, 100 tables/things -> probably ca. 5000 rows) but I see
this as the best way some of the things (column access, grant options,
roles) can be implemented in the first place and it will be much easier to
verify the implementation because you can read it right out of SQL.

It must be fast! It is watchword for this project. The ACL is checked
for each query. I agree with one global pg_acl for one DB.

Peter's point, if I understand it, is that pg_acl _cannot_ be global
per DB if we're striving for SQL compliance.

On the topic of SQL compliance: I spent some time this weekend looking
at the NIST's test suite for FIPS 127-2 (Federal Information Processing
Standard) This is the reg. that controls US gov't procurement of RDBMS
software, and includes by reference SQL92 (via ANSI and ISO docs.)

NIST was in the business of actually verifying conformance, until they
lost funding for it (Version 6.0 was released December 31, 1996). The test
suite is available from their website, and being a product of U.S. Gov't,
has no copyright.

http://www.itl.nist.gov/div897/ctg/sql_form.htm

My inital take is that the tests will be useful internally to test our
SQL92 conformance. So far, I've tried building the test schemas. During
building these, the privilege system get's a workout, with lots of GRANT
... WITH GRANT OPTION, etc. The other problem is accepting column specific
privileges, as well as column aliases in views specified like so:

CREATE VIEW viewname (alias1, alias2, alias3) AS ...

I rewrote those to use the SELECT something AS alias1 ... syntax.

I can continue on and run the 899 interactive SQL tests, as soon as I
figure out how the lack of SCHEMA support will impact them. It strikes me
that (future) SCHEMA support should impact the design for the ACL system.

I think caching can be done pretty effectively, too, since ACL items
rarely change once they're set up. I'm inclined to ask other people's
opinions on this item. Other than that, I think we have a winner
here. Time to bring this up the the rest of the folks and draw up a
project page ...

I think the general maxim: "Design for function, tune for performance"
may fit in here.

Agree. ...a project page with more details, implementation steps ..etc.

I'd be willing to assist in discussing what the SQL92 standard seems to
require for privileges.

Peter, you were just saying something about having three weeks free ... ;-)

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

From bouncefilter Mon Mar 6 18:05:05 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA97037
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Mar 2000 18:04:16 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id XAA22464;
Mon, 6 Mar 2000 23:12:39 GMT
Sender: lockhart@hub.org
Message-ID: <38C43B67.EEBF3964@alumni.caltech.edu>
Date: Mon, 06 Mar 2000 23:12:39 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TransactionStateData and AbsoluteTime
References: <Pine.LNX.4.21.0003051436470.347-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Shouldn't we use timestamp instead of AbsoluteTime in
TransactionStateData? It also gives more precision.

Thomas was hesitant to using 8 byte types internally across the board. He
must have his reasons.

Yes, I believe that I discussed it at that time, though not perhaps
all of these points:

I was hesitant to suggest a change which would increase the minimum
size of a tuple.

I was hesitant to tie the fundamental internal operation to modern
floating point performance on machines (it is only recently that float
calculations are comparable to ints).

On 64 bit machines especially, it may be interesting to do a 64 bit
int for the date/time types, which would give greater precision away
from Y2K, but a more limited total range.

To get a precision greater than 1 second, we would have to use a
different time call from the OS. I assume that one would be fairly
portable, but would then require a conversion of int8 to float, with
some runtime expense.

And I haven't seen a great demand for greater precision in the table
structures, though istm that it might be of interest.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Mon Mar 6 19:38:06 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA16485
for <pgsql-hackers@postgresql.org>; Mon, 6 Mar 2000 19:37:23 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12S802-000LELC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Mon, 6 Mar 2000 18:37:22 -0600 (CST)
Date: Mon, 6 Mar 2000 18:37:22 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: pgsql-hackers@postgresql.org
Subject: sqgfault on initdb with current CVS
Message-ID: <20000306183722.A7703@rice.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i

Sorry about the length of this one, but I wanted to include backtrace
info. I've been getting a segfault when I try to setup a test version
of the current CVS tree, to run along beside a 'production' 6.5.X server.

This is how I've configured it:

wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug

After which make; make install works fine.

On my machine at home, where I can let pgsql take the default location
and port, I've had no trouble. With this one, at work, I get a segfault
when initdb tries to execute postgres in bootstrap mode. I've managed
to run postgres under gdb and capture a backtrace:

wallace$ which initdb
/usr/local/pgsql7.0/bin/initdb
wallace$ export | grep -i PG
declare -x LD_LIBRARY_PATH="/usr/local/pgsql7.0/lib"
declare -x PGDATA="/usr/local/pgsql7.0/data"
declare -x PGLIB="/usr/local/pgsql7.0/lib"
declare -x PWD="/extra/src/pgsql-current/src"
{PATH deleted}

{already ran initdb -d -n, then, after it failed, deleted
${PGDATA}/pg_control, and created an already sed processed version of
the template (just subs for PGUID) }

wallace$ gdb postgres
GNU gdb 19990928
<deleted banner>
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) set args -boot -x -C -F -D/usr/local/pgsql7.0/data -d template1 </home/reedstrm/template1.sql
(gdb) run
Starting program: /usr/local/pgsql7.0/bin/postgres -boot -x -C -F -D/usr/local/pgsql7.0/data -d template1 </home/reedstrm/template1.sql
<proname name>
<proowner int4>
<prolang oid>
<proisinh bool>
<proistrusted bool>
<proiscachable bool>
<pronargs int2>
<proretset bool>
<prorettype oid>
<proargtypes oidvector>
<probyte_pct int4>
<properbyte_cpu int4>
<propercall_cpu int4>
<prooutin_ratio int4>
<prosrc text>
<probin bytea>

creating bootstrap relation

Program received signal SIGSEGV, Segmentation fault.
0x80eb266 in filepath (filename=0x81b2260 "pg_proc") at fd.c:529

529 len = strlen(DatabasePath) + strlen(filename) + 2;
(gdb) bt
#0 0x80eb26
#1 0x80eb456 in FileNameOpenFile (fileName=0x81b2260 "pg_proc", fileFlags=194, fileMode=384)
at fd.c:657
#2 0x80f1d44 in mdcreate (reln=0x81b18b0) at md.c:128
#3 0x80f2da7 in smgrcreate (which=0, reln=0x81b18b0) at smgr.c:134
#4 0x8081a9d in heap_storage_create (rel=0x81b18b0) at heap.c:352
#5 0x8081a4c in heap_create (relname=0x81b8d48 "pg_proc", tupDesc=0x81bdd28, isnoname=0 '\000',
istemp=0, storage_create=1 '\001') at heap.c:329
#6 0x807e95c in Int_yyparse () at bootparse.y:168
#7 0x8080557 in BootstrapMain (argc=7, argv=0xbffffc38) at bootstrap.c:395
#8 0x80afcee in main (argc=8, argv=0xbffffc34) at main.c:100

{grovel around in fd.c: looks like DatabasePath should be set by
SetDatabasePath, which uses ExpandDatabasePath to the value of DataDir +
dbName (template1) but somehow we missed it}

(gdb) print DatabasePath
$1 = 0x0
(gdb) print DataDir
$2 = 0xbffffd97 "/usr/local/pgsql7.0/data"
(gdb) exit

Anyone have any ideas? I can recreate at will.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

From bouncefilter Mon Mar 6 20:08:06 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA20000
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Mar 2000 20:07:24 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA04911;
Tue, 7 Mar 2000 10:07:17 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id KAA04616;
Tue, 7 Mar 2000 10:07:17 +0900
To: reedstrm@wallace.ece.rice.edu
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] sqgfault on initdb with current CVS
In-Reply-To: Your message of "Mon, 6 Mar 2000 18:37:22 -0600"
<20000306183722.A7703@rice.edu>
References: <20000306183722.A7703@rice.edu>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000307100716Q.t-ishii@sra.co.jp>
Date: Tue, 07 Mar 2000 10:07:16 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 14

Sorry about the length of this one, but I wanted to include backtrace
info. I've been getting a segfault when I try to setup a test version
of the current CVS tree, to run along beside a 'production' 6.5.X server.

This is how I've configured it:

wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug

For some reason, current does not seem to allow "." in the
$PGDATA. I'm no sure why this happens at all. I guess it intends to
inhibit "./" or "../" for a security reason? If so, that would be
apparently an overkill.
--
Tatsuo Ishii

From bouncefilter Mon Mar 6 20:36:07 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA23560
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Mar 2000 20:35:07 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA07169;
Tue, 7 Mar 2000 10:34:57 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id KAA05417;
Tue, 7 Mar 2000 10:34:57 +0900
To: lockhart@alumni.caltech.edu
Cc: peter_e@gmx.net, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TransactionStateData and AbsoluteTime
In-Reply-To: Your message of "Mon, 06 Mar 2000 23:12:39 +0000"
<38C43B67.EEBF3964@alumni.caltech.edu>
References: <38C43B67.EEBF3964@alumni.caltech.edu>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000307103456P.t-ishii@sra.co.jp>
Date: Tue, 07 Mar 2000 10:34:56 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 41

Shouldn't we use timestamp instead of AbsoluteTime in
TransactionStateData? It also gives more precision.

Thomas was hesitant to using 8 byte types internally across the board. He
must have his reasons.

Yes, I believe that I discussed it at that time, though not perhaps
all of these points:

I was hesitant to suggest a change which would increase the minimum
size of a tuple.

Can you tell me where the data/time info exists in HeapTupleData?
I could not find it.

I was hesitant to tie the fundamental internal operation to modern
floating point performance on machines (it is only recently that float
calculations are comparable to ints).

On 64 bit machines especially, it may be interesting to do a 64 bit
int for the date/time types, which would give greater precision away
from Y2K, but a more limited total range.

To get a precision greater than 1 second, we would have to use a
different time call from the OS. I assume that one would be fairly
portable, but would then require a conversion of int8 to float, with
some runtime expense.

Ok. currently we call GetCurrentAbsoluteTime() to get the transaction
start time. If we use timestamp instead of Abstime, we would call
timeofday() defined in nabstime.c or something like that. So it might
be interesting to see how the speed is different between these two
calls. If I have a spare time, I'll try it.

And I haven't seen a great demand for greater precision in the table
structures, though istm that it might be of interest.

Anyway, I think we don't want to see those none trivial changes to
appear in 7.0.
--
Tatsuo Ishii

From bouncefilter Mon Mar 6 22:34:08 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA56787
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Mar 2000 22:33:23 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA03864;
Mon, 6 Mar 2000 22:31:56 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003070331.WAA03864@candle.pha.pa.us>
Subject: Re: [HACKERS] Proposal for Grand Unified Configuration scheme
In-Reply-To: <Pine.LNX.4.21.0003061512190.362-100000@localhost.localdomain>
from Peter Eisentraut at "Mar 6, 2000 04:59:57 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Mon, 6 Mar 2000 22:31:56 -0500 (EST)
CC: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Peter Eisentraut wrote:

I have (almost) nothing to do for about 3 weeks, so I thought I'd get
started on some stuff for next time around.

Lucky you

The idea here is to unify all the various configuration settings into one
coherent scheme. This would include:

[...]

Let me know what you think. Don't be rushed if you have other things to do
right now.

Sounds good to me.

Jan from Philly

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Mar 7 00:05:10 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA69236
for <pgsql-hackers@postgresql.org>; Tue, 7 Mar 2000 00:04:45 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12SCAl-000LELC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Mon, 6 Mar 2000 23:04:43 -0600 (CST)
Date: Mon, 6 Mar 2000 23:04:43 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] sqgfault on initdb with current CVS
Message-ID: <20000306230443.A14691@rice.edu>
References: <20000306183722.A7703@rice.edu>
<20000307100716Q.t-ishii@sra.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <20000307100716Q.t-ishii@sra.co.jp>;
from t-ishii@sra.co.jp on Tue, Mar 07, 2000 at 10:07:16AM +0900

On Tue, Mar 07, 2000 at 10:07:16AM +0900, Tatsuo Ishii wrote:

Sorry about the length of this one, but I wanted to include backtrace
info. I've been getting a segfault when I try to setup a test version
of the current CVS tree, to run along beside a 'production' 6.5.X server.

This is how I've configured it:

wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug

For some reason, current does not seem to allow "." in the
$PGDATA. I'm no sure why this happens at all. I guess it intends to
inhibit "./" or "../" for a security reason? If so, that would be
apparently an overkill.

Thank you very much, Ishii-san, changing it to pgsql70 worked! If your ever in Houston,
I owe you a beer!

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

From bouncefilter Tue Mar 7 00:08:09 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA69485
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 00:07:45 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id FAA23123;
Tue, 7 Mar 2000 05:16:07 GMT
Sender: lockhart@hub.org
Message-ID: <38C49097.94F026E7@alumni.caltech.edu>
Date: Tue, 07 Mar 2000 05:16:07 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, reedstrm@wallace.ece.rice.edu,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] sqgfault on initdb with current CVS
References: <20000306183722.A7703@rice.edu>
<20000307100716Q.t-ishii@sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug

For some reason, current does not seem to allow "." in the
$PGDATA. I'm no sure why this happens at all. I guess it intends to
inhibit "./" or "../" for a security reason? If so, that would be
apparently an overkill.

Bruce, can you add this item to the "must fix" list for the 7.0
release (hint hint - is it time to start that list?? ;)

Also, please add to the same list:

o implement the OVERLAPS date/time operator from SQL92 (Thomas)
o support TIME WITH TIME ZONE timezones in literals (Thomas)
o add support for full POSIX time zone specification (Thomas)

The POSIX time zone stuff is already in there, new for this release,
but needs to be polished to work with TZs away from GMT. The OVERLAPS
stuff is coded and being tested now; it just adds a few functions and
a bit of gram.y syntax.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Mar 7 00:18:09 2000
Received: from S34EXCHANGE (s34gway.s34.co.jp [210.250.219.98])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA70823
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 00:17:42 -0500 (EST)
(envelope-from yutaka@marin.or.jp)
Received: from yutaka (S34GWay.s34.co.jp [210.250.219.98]) by S34EXCHANGE with
SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
id 1YT4CJS0; Tue, 7 Mar 2000 14:19:13 +0900
Date: Tue, 07 Mar 2000 14:25:22 +0900
From: yutaka tanida <yutaka@marin.or.jp>
To: Alexei Zakharov <A.S.Zakharov@inp.nsk.su>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] xlog.c.patch for cygwin port.
In-Reply-To: <003001bf8732$1c3df400$0101010a@magic>
References: <003001bf8732$1c3df400$0101010a@magic>
Message-Id: <38C492C232E.8E0EYUTAKA@s34gway.s34.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=Windows-1252
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.25.07

Hi,

On Mon, 6 Mar 2000 12:06:27 +0600
"Alexei Zakharov" <A.S.Zakharov@inp.nsk.su> wrote:

I suggest a following patch. BTW the situation appeared before,
see hba.c, pqcomm.c and others.

I propose another patch, against src/include/port/win.h.
If this patch is applied, #ifdef with open() such as following is no
more needed.

--
#ifndef __CYGWIN__
fd=open(path,flags,mode);
#else
fd=open(path,flags | O_BINARY,mode);
#endif
--

Comments?

--
Yutaka tanida / S34 Co., Ltd.
tanida@s34.co.jp (Office)
yutaka@marin.or.jp(Private, or if you *HATE* Microsoft Outlook)

*** win.h.orig	Thu Feb 10 17:00:14 2000
--- win.h	Tue Mar 07 14:07:21 2000
***************
*** 10,15 ****
--- 10,35 ----
  #define USE_POSIX_TIME
  #define HAVE_INT_TIMEZONE		/* has int _timezone */

+ /* open() must use with O_BINARY flag */
+ 
+ #include<stdarg.h>
+ #include<sys/fcntl.h>
+ 
+ static __inline int pg_cygwin_open(const char *pathname,int flags,...) {
+     va_list va;
+ 	mode_t mode;
+ 	if(flags | O_CREAT) {
+         va_start(va,flags);
+         mode=va_arg(va,int);
+         va_end(va);
+     	return open(pathname,flags | O_BINARY,mode);
+ 	}else{
+     	return open(pathname,flags | O_BINARY);
+ 	}
+ }
+ 
+ #define open pg_cygwin_open
+ 
  #include <cygwin/version.h>
  #if (CYGWIN_VERSION_API_MAJOR >= 0) && (CYGWIN_VERSION_API_MINOR >= 8)
  #define sys_nerr _sys_nerr

Peter Eisentraut <peter_e@gmx.net> writes:

Bruce Momjian writes:

Looks very nice, but we can't apply it during beta. Only bug fixes, and
this looks a little tricky. We can try it for 7.1. Maybe you can get
us a 7.0 based patch.

It was me that encouraged him to send in this patch now because Karel and
I are currently talking about redoing the ACL stuff for 7.1.

I considered this a bug and the fix looks pretty straightforward. Perhaps
it should go into 7.0.1?

It looked to me like a definition change that hadn't been adequately
discussed. We tend to be especially leery of those during beta;
rushing in a "bug fix" that may prove to have been a bad idea is
not productive.

regards, tom lane

From bouncefilter Tue Mar 7 01:56:10 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA79141
for <pgsql-hackers@postgresql.org>; Tue, 7 Mar 2000 01:55:37 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA19110;
Tue, 7 Mar 2000 01:55:21 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Mark Jewiss <mark.jewiss@knowledge.com>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [GENERAL] Version 7.0 beta problem
In-reply-to: <Pine.LNX.4.21.0003040418470.489-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0003040418470.489-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Sat, 04 Mar 2000 18:06:11 +0100"
Date: Tue, 07 Mar 2000 01:55:21 -0500
Message-ID: <19107.952412121@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

Mark Jewiss writes:

mainloop.c:43: warning: variable `successResult' might be clobbered by `longjmp' or `vfork'

I thought I had shut up those warnings by making the variables in question
volatile. There's no need to worry about them since they're re-initialized
right after the longjmp, but does anyone know how to shut up the compiler?

That *should* shut up these warnings. Maybe Mark is trying a slightly
back-dated beta version? I know you didn't have the "volatile"s in
there a few days ago.

regards, tom lane

From bouncefilter Tue Mar 7 01:59:11 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA79357
for <pgsql-hackers@postgresql.org>; Tue, 7 Mar 2000 01:58:30 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA19138;
Tue, 7 Mar 2000 01:58:22 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
In-reply-to: <Pine.LNX.4.21.0003040427210.489-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0003040427210.489-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Sat, 04 Mar 2000 18:06:37 +0100"
Date: Tue, 07 Mar 2000 01:58:22 -0500
Message-ID: <19134.952412302@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

In turn I'm thinking that it might be nice to have a backend function like
format_type(name[, int4]) that formats an internal type and any size
modifier for client consumption, like

format_type('varchar', 8) => "CHARACTER VARYING(8)"
format_type('my type') => "\"my type\""
format_type('numeric', {xxx}) => "NUMERIC(9,2)"

That could put an end to keeping track of backend implementation details
in psql, pg_dump, and friends.

Seems like a good idea, though I think it's a bit late in the 7.0 cycle
for such a change. Maybe for 7.1?

Also, I assume you mean that the int4 arg would be the typmod value ---
your examples are not right in detail for that interpretation.

regards, tom lane

From bouncefilter Tue Mar 7 02:55:13 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA85847
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 02:54:18 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id CAA19329;
Tue, 7 Mar 2000 02:53:49 -0500 (EST)
To: Mike Mascari <mascarm@mascari.com>
cc: Peter Eisentraut <peter_e@gmx.net>, Tatsuo Ishii <t-ishii@sra.co.jp>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
In-reply-to: <38C30A6D.FC8D2AD9@mascari.com>
References: <Pine.LNX.4.21.0003051434090.347-100000@localhost.localdomain>
<38C30A6D.FC8D2AD9@mascari.com>
Comments: In-reply-to Mike Mascari <mascarm@mascari.com>
message dated "Sun, 05 Mar 2000 20:31:25 -0500"
Date: Tue, 07 Mar 2000 02:53:49 -0500
Message-ID: <19326.952415629@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Mike Mascari <mascarm@mascari.com> writes:

So, as some sort of compromise, a NOTICE was issued.

It seems everybody but Mike has forgotten the previous go-round on
this issue. I had in fact put in an ERROR for DROP TABLE inside a
transaction block, and was beat up for it --- on the very reasonable
grounds that it's useful to be able to drop a table and do some other
things inside a transaction. Although we can't support rollback-ability
for such a transaction right now, we *do* support the atomic nature of
such a transaction. It's not reasonable to take away a capability that
was available in prior releases just because it's got deficiencies.
So the compromise was to issue a NOTICE instead of an ERROR.

BTW, we are not *that* far from being able to roll back a DROP TABLE.
The only thing that's really needed is for everyone to take a deep
breath and let go of the notion that table files ought to be named
after the tables. If we named table files after the OIDs of their
tables, then rollback-able DROP or RENAME TABLE would be pretty
straightforward. If you don't recall why this is, consult the
pghackers archives...

regards, tom lane

From bouncefilter Tue Mar 7 03:07:13 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA91494
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 03:06:57 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id RAA02475;
Tue, 7 Mar 2000 17:06:45 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id RAA11506;
Tue, 7 Mar 2000 17:06:43 +0900
To: tgl@sss.pgh.pa.us
Cc: mascarm@mascari.com, peter_e@gmx.net, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
In-Reply-To: Your message of "Tue, 07 Mar 2000 02:53:49 -0500"
<19326.952415629@sss.pgh.pa.us>
References: <19326.952415629@sss.pgh.pa.us>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000307170643S.t-ishii@sra.co.jp>
Date: Tue, 07 Mar 2000 17:06:43 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 25

It seems everybody but Mike has forgotten the previous go-round on
this issue. I had in fact put in an ERROR for DROP TABLE inside a
transaction block, and was beat up for it --- on the very reasonable
grounds that it's useful to be able to drop a table and do some other
things inside a transaction. Although we can't support rollback-ability
for such a transaction right now, we *do* support the atomic nature of
such a transaction. It's not reasonable to take away a capability that
was available in prior releases just because it's got deficiencies.
So the compromise was to issue a NOTICE instead of an ERROR.

BTW, we are not *that* far from being able to roll back a DROP TABLE.
The only thing that's really needed is for everyone to take a deep
breath and let go of the notion that table files ought to be named
after the tables. If we named table files after the OIDs of their
tables, then rollback-able DROP or RENAME TABLE would be pretty
straightforward. If you don't recall why this is, consult the
pghackers archives...

So what was the conclusion for 7.0?

Disallow DROP TABLE/DROP INDEX inside a transaction block

We should remove above from HISTORY, no?
--
Tatsuo Ishii

From bouncefilter Tue Mar 7 03:10:15 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA91825
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 03:09:17 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id DAA19363;
Tue, 7 Mar 2000 03:08:35 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Brian Hirt <bhirt@mobygames.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Optimizer badness in 7.0 beta
In-reply-to: <Pine.GSO.4.02A.10003060759180.17581-100000@Svan.DoCS.UU.SE>
References: <Pine.GSO.4.02A.10003060759180.17581-100000@Svan.DoCS.UU.SE>
Comments: In-reply-to Peter Eisentraut <e99re41@DoCS.UU.SE>
message dated "Mon, 06 Mar 2000 08:05:52 +0100"
Date: Tue, 07 Mar 2000 03:08:35 -0500
Message-ID: <19360.952416515@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

I dont know too much about the PG internals, but when I used sybase,
it would usually execute the sub-select independently and stuff the
results into a temp table and then do another query, joining to the
results of the sub-select.

Last time I checked PostgreSQL executes the subquery for each row.
Apparently it must still be doing that

It did up until last Wednesday. If Brian retries his example with
current sources I think he'll see better performance. But I still
want to poke into exactly why the indexscan implementation seems so
much slower than the prior seqscan+sort implementation; that doesn't
seem right. (And if it is right, why doesn't the optimizer realize it?)
I'll get back to Brian on that.

and I do suspect that it is right
in the overall sense because the subquery may have side effects. Consider

SELECT * FROM t1 WHERE id IN (select nextval('my_sequence'))

Of course this query makes absolutely no sense whatsoever but perhaps
there are similar ones where it does.

Interesting example. But since the tuples in t1 are not guaranteed to
be scanned in any particular order, it seems to me that a query that
has side-effects in WHERE inherently has undefined results. If we could
detect side-effect-producing expressions (which we cannot, currently,
and in general I suspect that problem is undecidable) I would argue that
we ought to reject this query. I certainly don't want to constrain the
optimizer by assuming that repeated executions of subqueries can't be
optimized away.

regards, tom lane

From bouncefilter Tue Mar 7 03:17:14 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA92930
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 03:16:13 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id DAA19388;
Tue, 7 Mar 2000 03:15:31 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Proposal for Grand Unified Configuration scheme
In-reply-to: <Pine.LNX.4.21.0003061512190.362-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0003061512190.362-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Mon, 06 Mar 2000 16:59:57 +0100"
Date: Tue, 07 Mar 2000 03:15:31 -0500
Message-ID: <19385.952416931@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

The idea here is to unify all the various configuration settings into one
coherent scheme.

A good goal. Your sketch seems reasonable, but one comment:

... For
example it would be nice if I could start the postmaster with the -F
option and it would look that up in the grand unified options table (see
above) and say "ah, that's a per-backend option" and pass it on to the
backend.

In fact -F is *not* a per-backend option, and certainly we dare not
change it on-the-fly via SET. The setting is useless and even dangerous
unless all backends are behaving the same way (see pghackers archives if
you've forgotten why). More generally, some options are reasonable to
set at any time and some aren't; your mechanism needs to deal with that.

regards, tom lane

From bouncefilter Tue Mar 7 20:18:32 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA49643
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 20:17:45 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id UAA06089
for pgsql-hackers@postgreSQL.org; Tue, 7 Mar 2000 20:17:12 -0500 (EST)
Received: from siauto.it (a-pd21-28.tin.it [212.216.45.219])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id EAA09482
for <pgman@candle.pha.pa.us>; Tue, 7 Mar 2000 04:32:36 -0500 (EST)
Received: from pierino by siauto.it with SMTP (MDaemon.v2.8.7.2.R)
for <pgman@candle.pha.pa.us>; Tue, 07 Mar 2000 09:47:31 +0100
Message-ID: <006901bf8812$02f59120$0a0aa8c0@pierino>
From: "Jacopo Silva" <jsilva@siauto.it>
To: <pgman@candle.pha.pa.us>
Subject: pSQL auth
Date: Tue, 7 Mar 2000 09:45:44 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-MDaemon-Deliver-To: pgman@candle.pha.pa.us
X-Return-Path: JSilva@siauto.it
Sender: pgman@candle.pha.pa.us

Hello.

I noticed you are the maintainer of the TODO list for PostgreSQL.

I am an enthusiastic user of PostgreSQL, and I feel that with little effort
we could add pam authentication functionality. What do you think?
"Pluggable Authentication Modules" are well supported on many architectures,
eg. Linux or BSD or Solaris, users could authenticate in tens of ways.
The db administrator's will have choice of thousands of authentication
methods, e.g. Kerberos, standard Unix UID (/etc/passwd), SMB, NT Domain,
etc. etc.
I am looking forward for a NT Domain authentication for PostgreSQL, but
others could use one the thousands pam provide.

And also you will not have to mantain any more an "authentication tree" on
the PostgreSQL source code. You just delegate to pam libraries.

Thanks for evaluating my proposal,
Jacopo Silva

On Tue, 7 Mar 2000, Tom Lane wrote:

It looked to me like a definition change that hadn't been adequately
discussed. We tend to be especially leery of those during beta;
rushing in a "bug fix" that may prove to have been a bad idea is
not productive.

ok, but what are you planning to do and when to correct this security
issue ?

I agree it's not a complete rewrite of acls in postgresql, which maybe (I
don't know) need to be rewritten from scratch, because I'm really not able
to do this. However saying that a quick fix to correct a major security
problem is a bad idea makes me laugh loudly (or cry, if you prefer).

for now and until someone acts correctly regarding this problem, I'll
patch my good old 6.5.2 version and use it, and you can throw my patch in
your ass or wherever you prefer if you don't want it.

Don't even expect me to rewrite this patch for 7.0, because it's not my
problem anymore, it's yours (and other postgresql users') !

I really don't mind you don't include my patch in postgresql, what I'm
concerned about is that you don't plan anything to quickly solve this
problem. Maybe you don't know, which would surprise me, but some people
write programs which rely on acls and other SQL features working
correctly.

At least you should document this security problem.

Don't try to tell me to use another product, because unfortunately for you
I really like postgresql.

thank you for reading.

Peter: thanks again for your support.

bye,

Jerome

From bouncefilter Tue Mar 7 09:53:16 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA61070
for <pgsql-hackers@postgresql.org>; Tue, 7 Mar 2000 09:52:30 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1) id 12SLLf-0006U2-00
for pgsql-hackers@postgresql.org; Tue, 7 Mar 2000 14:52:35 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12SLLX-0002V7-00
for pgsql-hackers@postgresql.org; Tue, 7 Mar 2000 14:52:27 +0000
Date: Tue, 7 Mar 2000 14:52:27 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: pgsql-hackers@postgresql.org
Subject: alter_table.sql
Message-ID: <20000307145227.H9329@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i

In the alter table regression test, alter_table.sql, it says:

-- 20 values, sorted
SELECT unique1 FROM ten_k WHERE unique1 < 20;

-- 20 values, sorted
SELECT unique2 FROM ten_k WHERE unique2 < 20;

Why sorted? Shouldn't it be

SELECT unique1 FROM ten_k WHERE unique1 < 20 ORDER BY unique1;

if we really expect the output to be sorted?

Cheers,

Patrick

From bouncefilter Tue Mar 7 10:09:16 2000
Received: from feivel.fam-meskes.de (pC19EBEB5.dip0.t-ipconnect.de
[193.158.190.181]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA67952
for <pgsql-hackers@postgresql.org>; Tue, 7 Mar 2000 10:08:34 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 2E5F62BC0F; Tue, 7 Mar 2000 15:57:46 +0100 (CET)
Date: Tue, 7 Mar 2000 15:57:45 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: library policy question
Message-ID: <20000307155745.A1251@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Sender: michael@fam-meskes.de

What exactly is our policy towards global variables in libraries? I take is
these variables are harmless in multi tasking operation as each process has
its seperate data space. But they may do harm in multi threading. But then
libpq are is not suitable for multi threading, is it?

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Tue Mar 7 10:09:16 2000
Received: from feivel.fam-meskes.de (pC19EBEB5.dip0.t-ipconnect.de
[193.158.190.181]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA68692
for <pgsql-hackers@postgresql.org>; Tue, 7 Mar 2000 10:09:02 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 1471F2BC10; Tue, 7 Mar 2000 16:09:39 +0100 (CET)
Date: Tue, 7 Mar 2000 16:09:39 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: ECPG restructuring
Message-ID: <20000307160939.A1956@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Sender: michael@fam-meskes.de

I had to change quite a lot of files to make libepcg easier to handle. It
may be I accidently deleted too many include file. It does compile on my
linux machine though. So if it does not compile on any other system please
tell me.

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Tue Mar 7 10:42:17 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA77389
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 10:42:04 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA23807;
Tue, 7 Mar 2000 15:47:04 GMT
Sender: lockhart@hub.org
Message-ID: <38C52478.42D74BAF@alumni.caltech.edu>
Date: Tue, 07 Mar 2000 15:47:04 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Peter Eisentraut <peter_e@gmx.net>,
Bruce Momjian <pgman@candle.pha.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
References: <Pine.LNX.4.21.0003040427210.489-100000@localhost.localdomain>
<19134.952412302@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

format_type(name[, int4]) that formats an internal type and any size
modifier for client consumption, like
format_type('varchar', 8) => "CHARACTER VARYING(8)"
format_type('my type') => "\"my type\""
format_type('numeric', {xxx}) => "NUMERIC(9,2)"

Ooh, that *is* a good idea (though the exact name of the function may
evolve)! Sorry I missed seeing it in Peter's earlier postings.

Funny how we can go for years banging our heads on an issue and have
something like this (ie a good idea on the subject) pop up out of the
blue.

Presumably we would include a function taking the conversion the other
direction too...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Mar 7 11:15:17 2000
Received: from imcwaw2.polkomtel.com.pl (imcwaw2.polkomtel.com.pl
[212.2.96.79]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA86266
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 11:15:09 -0500 (EST)
(envelope-from andrzej.mazurkiewicz@polkomtel.com.pl)
Received: by imcwaw2.plusnet with Internet Mail Service (5.5.2448.0)
id <Z35QGWYX>; Tue, 7 Mar 2000 17:14:34 +0100
Message-ID: <13288F4408ADD11186FF0060B06A431303648CA8@MSGWAW1>
From: Andrzej Mazurkiewicz <andrzej.mazurkiewicz@polkomtel.com.pl>
To: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: How can I create trigger on system table, for on example pg_class ???
Date: Tue, 7 Mar 2000 17:14:30 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Thanks,
Regards,
Andrzej Mazurkiewicz

From bouncefilter Tue Mar 7 11:06:17 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA83618
for <hackers@postgresql.org>; Tue, 7 Mar 2000 11:05:58 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA23867
for <hackers@postgresql.org>; Tue, 7 Mar 2000 16:14:35 GMT
Sender: lockhart@hub.org
Message-ID: <38C52AEB.87DF5035@alumni.caltech.edu>
Date: Tue, 07 Mar 2000 16:14:35 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgresql.org>
Subject: CREATE VIEW fix
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've got patches to fix the CREATE VIEW command to support SQL92
syntax for result column names, a la

CREATE VIEW (a, b, c) AS SELECT ...

It is an almost trivial fix, requiring the addition of a single field
in the View structure and a few lines of code in analyze.c.

I'll commit this at the same time I commit support for the SQL92
OVERLAPS operator, which will need an initdb anyway since there are a
few new functions in pg_proc. I believe that we have at least one
other patch coming which will force an initdb anyway, and I'll
coordinate with that.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Mar 7 11:20:18 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA87541
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 11:19:20 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA20336;
Tue, 7 Mar 2000 11:19:08 -0500 (EST)
To: prlw1@cam.ac.uk
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] alter_table.sql
In-reply-to: <20000307145227.H9329@quartz.newn.cam.ac.uk>
References: <20000307145227.H9329@quartz.newn.cam.ac.uk>
Comments: In-reply-to Patrick Welche <prlw1@newn.cam.ac.uk>
message dated "Tue, 07 Mar 2000 14:52:27 +0000"
Date: Tue, 07 Mar 2000 11:19:08 -0500
Message-ID: <20333.952445948@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

In the alter table regression test, alter_table.sql, it says:
-- 20 values, sorted
SELECT unique1 FROM ten_k WHERE unique1 < 20;
Why sorted? Shouldn't it be
SELECT unique1 FROM ten_k WHERE unique1 < 20 ORDER BY unique1;
if we really expect the output to be sorted?

The regression test author evidently expected the optimizer to choose an
indexscan, which will produce the values in sorted order as a byproduct.
I agree this code is bogus in a theoretical sense, but I don't think
it's worth worrying about until we alter the optimizer so far that it
doesn't choose an indexscan for this query. (Indeed, that might be a
sign of an optimizer bug --- so I'd look into why the behavior changed
before changing the regress test.)

Since our regress tests are checked on the basis of exact equality of
output, in theory every single regress test SELECT that doesn't specify
"ORDER BY" is broken, because in theory the system could choose to put
out the tuples in some other order than what's in the regress test
reference outputs. But in practice, the implementation-dependent
ordering you get is reproducible across platforms, so the tests
accomplish what they're supposed to. Every so often we have to throw in
an ORDER BY when we find that one of the test cases isn't so
reproducible.

regards, tom lane

From bouncefilter Tue Mar 7 11:34:17 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA92632;
Tue, 7 Mar 2000 11:34:10 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA20380;
Tue, 7 Mar 2000 11:34:04 -0500 (EST)
To: Michael Meskes <meskes@postgreSQL.org>
cc: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] library policy question
In-reply-to: <20000307155745.A1251@fam-meskes.de>
References: <20000307155745.A1251@fam-meskes.de>
Comments: In-reply-to Michael Meskes <meskes@postgreSQL.org>
message dated "Tue, 07 Mar 2000 15:57:45 +0100"
Date: Tue, 07 Mar 2000 11:34:04 -0500
Message-ID: <20377.952446844@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Michael Meskes <meskes@postgreSQL.org> writes:

What exactly is our policy towards global variables in libraries?

Avoid them.

But then libpq are is not suitable for multi threading, is it?

AFAIK, libpq's only use of non-constant globals is the ill-designed
PQconninfoOption array. I'd get rid of that if it didn't mean breaking
the library API. But as things stand, you can't safely use concurrent
calls to PQconnectdb or PQconndefaults. Everything else should be OK,
unless someone has broken it recently.

(idly examines code...)

Hmm, we do have a bit of a problem here. While PQconnectdb can be
replaced by PQsetdb to avoid the concurrency issue, there is no
thread-safe equivalent for the new routines
PQconnectStart/PQconnectPoll. That may not matter much, because
probably you would only need those in a single-threaded environment,
but it's still kinda ugly. In any case it'd be a lot nicer to be
able to say "libpq is thread safe" rather than "almost thread safe".

At one point we had discussed going ahead and breaking compatibility
in order to get rid of the static PQconninfoOption array. It wouldn't
be a big change in the API: we'd only need to make PQconndefaults return
a malloc'd array instead of a static. That probably wouldn't really
break any existing code, just create a small memory leak in applications
that didn't know to free the result when they were done with it. My bet
is that very few apps use PQconndefaults anyway.

7.0 would be a good time to do that if we were gonna do it. Comments?

regards, tom lane

From bouncefilter Tue Mar 7 11:42:17 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA94980
for <pgsql-hackers@postgresql.org>; Tue, 7 Mar 2000 11:41:54 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12SN2H-0006aS-00; Tue, 7 Mar 2000 16:40:41 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12SN27-0002uq-00; Tue, 7 Mar 2000 16:40:31 +0000
Date: Tue, 7 Mar 2000 16:40:31 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] alter_table.sql
Message-ID: <20000307164031.L9329@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <20000307145227.H9329@quartz.newn.cam.ac.uk>
<20333.952445948@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <20333.952445948@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Tue, Mar 07, 2000 at 11:19:08AM -0500

OK - got it! It is because vacuum analyze <tablename> doesn't work for me,
therefore the select doesn't use indices, so uses a sequential rather than
index scan => my rows are returned out of order.

Thanks for the pointer.

Cheers,

Patrick

On Tue, Mar 07, 2000 at 11:19:08AM -0500, Tom Lane wrote:

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

In the alter table regression test, alter_table.sql, it says:
-- 20 values, sorted
SELECT unique1 FROM ten_k WHERE unique1 < 20;
Why sorted? Shouldn't it be
SELECT unique1 FROM ten_k WHERE unique1 < 20 ORDER BY unique1;
if we really expect the output to be sorted?

The regression test author evidently expected the optimizer to choose an
indexscan, which will produce the values in sorted order as a byproduct.
I agree this code is bogus in a theoretical sense, but I don't think
it's worth worrying about until we alter the optimizer so far that it
doesn't choose an indexscan for this query. (Indeed, that might be a
sign of an optimizer bug --- so I'd look into why the behavior changed
before changing the regress test.)

Since our regress tests are checked on the basis of exact equality of
output, in theory every single regress test SELECT that doesn't specify
"ORDER BY" is broken, because in theory the system could choose to put
out the tuples in some other order than what's in the regress test
reference outputs. But in practice, the implementation-dependent
ordering you get is reproducible across platforms, so the tests
accomplish what they're supposed to. Every so often we have to throw in
an ORDER BY when we find that one of the test cases isn't so
reproducible.

regards, tom lane

From bouncefilter Tue Mar 7 11:48:19 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA97118
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 11:47:58 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA20413;
Tue, 7 Mar 2000 11:47:16 -0500 (EST)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: mascarm@mascari.com, peter_e@gmx.net, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
In-reply-to: <20000307170643S.t-ishii@sra.co.jp>
References: <19326.952415629@sss.pgh.pa.us>
<20000307170643S.t-ishii@sra.co.jp>
Comments: In-reply-to Tatsuo Ishii <t-ishii@sra.co.jp>
message dated "Tue, 07 Mar 2000 17:06:43 +0900"
Date: Tue, 07 Mar 2000 11:47:15 -0500
Message-ID: <20410.952447635@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

BTW, we are not *that* far from being able to roll back a DROP TABLE.
The only thing that's really needed is for everyone to take a deep
breath and let go of the notion that table files ought to be named
after the tables. If we named table files after the OIDs of their
tables, then rollback-able DROP or RENAME TABLE would be pretty
straightforward. If you don't recall why this is, consult the
pghackers archives...

So what was the conclusion for 7.0?

Too late to consider it for 7.0, I think. I'd like to see it happen in
7.1 or 7.2 or so.

Disallow DROP TABLE/DROP INDEX inside a transaction block

We should remove above from HISTORY, no?

Yes, it's not correct.

regards, tom lane

From bouncefilter Tue Mar 7 11:49:17 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA97658;
Tue, 7 Mar 2000 11:49:13 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA23931;
Tue, 7 Mar 2000 16:57:45 GMT
Sender: lockhart@hub.org
Message-ID: <38C53509.EAE64BDE@alumni.caltech.edu>
Date: Tue, 07 Mar 2000 16:57:45 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] library policy question
References: <20000307155745.A1251@fam-meskes.de>
<20377.952446844@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

7.0 would be a good time to do that if we were gonna do it. Comments?

Yup.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Mar 7 11:58:18 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA00803;
Tue, 7 Mar 2000 11:58:14 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id LAA14778;
Tue, 7 Mar 2000 11:58:11 -0500
Message-ID: <38C5350E.A76F705E@wgcr.org>
Date: Tue, 07 Mar 2000 11:57:50 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] library policy question
References: <20000307155745.A1251@fam-meskes.de>
<20377.952446844@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

but it's still kinda ugly. In any case it'd be a lot nicer to be
able to say "libpq is thread safe" rather than "almost thread safe".

7.0 would be a good time to do that if we were gonna do it. Comments?

If time is available to do that, I agree that now is an great time to do
so. As a user of a multithreaded web front end to PostgreSQL
(AOLserver), I personally am affected by the result. The AOLserver
PostgreSQL driver avoids the PQconnectdb() issue by using
PQsetdbLogin().

HOWEVER, it was a hunt to find that information -- it would have been
nice for the docs to say 'libpq {is|is not} threadsafe' -- even 'libpq
is threadsafe if and only if the following API calls are used:' would be
nice.
In fact, even if libpq is not touched, a documentation note to libpq's
threadsafeness would be nice.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Tue Mar 7 12:02:18 2000
Received: from clio.trends.ca (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA02049
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 12:01:50 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id MAA08968
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 12:01:45 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA20487;
Tue, 7 Mar 2000 12:01:30 -0500 (EST)
To: prlw1@cam.ac.uk
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] alter_table.sql
In-reply-to: <20000307164031.L9329@quartz.newn.cam.ac.uk>
References: <20000307145227.H9329@quartz.newn.cam.ac.uk>
<20333.952445948@sss.pgh.pa.us>
<20000307164031.L9329@quartz.newn.cam.ac.uk>
Comments: In-reply-to Patrick Welche <prlw1@newn.cam.ac.uk>
message dated "Tue, 07 Mar 2000 16:40:31 +0000"
Date: Tue, 07 Mar 2000 12:01:29 -0500
Message-ID: <20484.952448489@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

OK - got it! It is because vacuum analyze <tablename> doesn't work for me,
therefore the select doesn't use indices, so uses a sequential rather than
index scan => my rows are returned out of order.

Ah so. I think you mentioned before that you were seeing trouble with
VACUUM ANALYZE --- we need to find out what the problem is. What
platform are you on, and what are you seeing exactly?

regards, tom lane

From bouncefilter Tue Mar 7 12:23:18 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA07260
for <pgsql-hackers@postgresql.org>; Tue, 7 Mar 2000 12:22:17 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12SNgg-0006cA-00; Tue, 7 Mar 2000 17:22:26 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12SNgV-0002wu-00; Tue, 7 Mar 2000 17:22:15 +0000
Date: Tue, 7 Mar 2000 17:22:15 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] alter_table.sql
Message-ID: <20000307172215.M9329@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <20000307145227.H9329@quartz.newn.cam.ac.uk>
<20333.952445948@sss.pgh.pa.us>
<20000307164031.L9329@quartz.newn.cam.ac.uk>
<20484.952448489@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <20484.952448489@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Tue, Mar 07, 2000 at 12:01:29PM -0500

On Tue, Mar 07, 2000 at 12:01:29PM -0500, Tom Lane wrote:

Ah so. I think you mentioned before that you were seeing trouble with
VACUUM ANALYZE --- we need to find out what the problem is. What
platform are you on, and what are you seeing exactly?

When I mentioned it Bruce said "works for me" => I assume it is netbsd
specific => I should fix it! The symptom is, if I say
vacuum analyze <tablename>, I get

NOTICE: Vacuum: table not found
VACUUM

If I omit the tablename, vacuum analyze works. I have been rather pressed
for time, so all I can say is the notice comes from line 360 of
src/backend/commands/vacuum.c...

Cheers,

Patrick

From bouncefilter Wed Mar 8 01:25:28 2000
Received: from feivel.fam-meskes.de (h-62.96.149.131.host.de.colt.net
[62.96.149.131]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA34893
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Mar 2000 01:25:11 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 187582BC0C; Tue, 7 Mar 2000 20:25:10 +0100 (CET)
Date: Tue, 7 Mar 2000 20:25:10 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] library policy question
Message-ID: <20000307202510.A1211@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
References: <20000307155745.A1251@fam-meskes.de>
<20377.952446844@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <20377.952446844@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Tue, Mar 07, 2000 at 11:34:04AM -0500
Sender: michael@fam-meskes.de

On Tue, Mar 07, 2000 at 11:34:04AM -0500, Tom Lane wrote:

What exactly is our policy towards global variables in libraries?

Avoid them.

And what shall I do with sqlca? Make every program define it in its own space?

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Tue Mar 7 14:26:19 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA57162
for <pgsql-hackers@postgresql.org>; Tue, 7 Mar 2000 14:25:46 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12SPbf-000LEMC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Tue, 7 Mar 2000 13:25:23 -0600 (CST)
Date: Tue, 7 Mar 2000 13:25:23 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Mike Mascari <mascarm@mascari.com>, Peter Eisentraut <peter_e@gmx.net>,
Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgresql.org
Subject: SCHEMA support (was Re: DROP TABLE inside a transaction block)
Message-ID: <20000307132523.C21828@rice.edu>
References: <Pine.LNX.4.21.0003051434090.347-100000@localhost.localdomain>
<38C30A6D.FC8D2AD9@mascari.com> <19326.952415629@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <19326.952415629@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Tue, Mar 07, 2000 at 02:53:49AM -0500

On Tue, Mar 07, 2000 at 02:53:49AM -0500, Tom Lane wrote:

Mike Mascari <mascarm@mascari.com> writes:

So, as some sort of compromise, a NOTICE was issued.

BTW, we are not *that* far from being able to roll back a DROP TABLE.
The only thing that's really needed is for everyone to take a deep
breath and let go of the notion that table files ought to be named
after the tables. If we named table files after the OIDs of their
tables, then rollback-able DROP or RENAME TABLE would be pretty
straightforward. If you don't recall why this is, consult the
pghackers archives...

Another data point regarding table filenames: I've been looking into
what's needed to support SQL92 schemas.

The standard defines a hierarchy of what are essentially scopes for
database objects. They are (in order from high to low):

Cluster of catalogs -> catalog -> schema -> (DB objects)

"Cluster of catalogs" is defined as (section 4.13):

Exactly one cluster is associated with an SQL-session and it defines
the totality of the SQL-data that is available to that SQL-session.

A catalog is (section 4.12):

Catalogs are named collections of schemas in an SQL-environment. An
SQL-environment contains zero or more catalogs. A catalog con-
tains one or more schemas, but always contains a schema named
INFORMATION_SCHEMA that contains the views and domains of the
Information Schema.

catalog and schema names show up in the syntax, e.g. the BNF for table
names (section 5.4):

<table name> ::=
<qualified name>
<qualified name> ::=
[ <schema name> <period> ] <qualified identifier>

<qualified identifier> ::= <identifier> <schema name> ::=
[ <catalog name> <period> ] <unqualified schema name>

Which collapses to (using unique names for the various identifiers):

<table name> ::= [ <catalog indentifier> <period> ] [ <schema indentifier>
<period> ]
<table identifier>

and make a fully qualified column name BNF:

[ <catalog identifier> <period> ] [ <schema identifier> <period> ]
[ <table identifier> <period> ] <column identifier>

so:
foo.bar.baz.bongo

is a well formed column identifier for column bongo of table baz in
schema bar in catalog foo.

What's all this mean for pgsql? Well, SCHEMA are an Entry SQL
requirement. So, the syntax: schema.table needs to be supported. Both
schema and catalog define persistent visibilty scopes, and we need to
support identical table names in multiple schema.

I see two possiblities:

1) Map a pgsql database to a SQL schema.

Since we need to support identical table names in multiple schema,
it might be tempting to map a pgsql database to a schema. In fact,
since Entry SQL requires the syntax:

CREATE SCHEMA <schema authorization identifier>

And, in practice, the SCHEMA name seems to be equal to the database user
name, the pgsql default of creating (and accessing) a DB matching the
username implies this mapping.

However, that means we need to solve the one backend accessing multiple
DBs problem. I have a feeling that there may be 'gotchas' in the current
backend code that presume that all the tuples are coming from one DB.

2) Map pgsql DB -> SQL catalog

If we do this, the multiDB access problem can be pushed down the road,
since cross catalog access (<catalog name> in identifiers) is not
even required by Intermediate SQL, only Full SQL. In addition, almost
everything about catalogs is 'implemetation defined' so we get to claim
them as done. ;-)

2a) However, if a single pgsql database is a catalog, then each DB needs
to be able to contain tables in multiple schema, potentially with the
identical table names. One solution would be to do what we do for DBs:
create seperate subdirs for each schema, and put the table files in there.
Changes are probably isolated to the storage manager code, but I haven't
looked in detail.

2b) Another possiblity is what Tom has suggested, to solve the DDL
statements in a transaction problem: use some other unique identifier
for table filenames, perhaps based on OID. Then, supporting schemas
means supporting the syntax in the parser, and that's it, I think. This
would seem to minimize the changes needed to implement this Entry SQL92
requirement.

So, what do y'all think?

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

From bouncefilter Tue Mar 7 14:30:19 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA57977
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 14:29:42 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id OAA20880;
Tue, 7 Mar 2000 14:29:33 -0500 (EST)
To: prlw1@cam.ac.uk
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] alter_table.sql
In-reply-to: <20000307172215.M9329@quartz.newn.cam.ac.uk>
References: <20000307145227.H9329@quartz.newn.cam.ac.uk>
<20333.952445948@sss.pgh.pa.us>
<20000307164031.L9329@quartz.newn.cam.ac.uk>
<20484.952448489@sss.pgh.pa.us>
<20000307172215.M9329@quartz.newn.cam.ac.uk>
Comments: In-reply-to Patrick Welche <prlw1@newn.cam.ac.uk>
message dated "Tue, 07 Mar 2000 17:22:15 +0000"
Date: Tue, 07 Mar 2000 14:29:32 -0500
Message-ID: <20877.952457372@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

On Tue, Mar 07, 2000 at 12:01:29PM -0500, Tom Lane wrote:

Ah so. I think you mentioned before that you were seeing trouble with
VACUUM ANALYZE --- we need to find out what the problem is. What
platform are you on, and what are you seeing exactly?

When I mentioned it Bruce said "works for me" => I assume it is netbsd
specific => I should fix it! The symptom is, if I say
vacuum analyze <tablename>, I get

NOTICE: Vacuum: table not found
VACUUM

If I omit the tablename, vacuum analyze works.

Hmm. Since there have been examples of vacuum analyze <tablename> in
the numeric regress test since 6.5, I'd think we'd have heard about it
if there were any widespread problem ;-). Perhaps it is a platform
issue, but I suspect you will find there are additional constraints that
explain why no one but you is seeing it. Please do dig into it ... or,
if you do not have time, you could consider giving one of the other
developers a login on your machine and that person could check it out.

regards, tom lane

From bouncefilter Tue Mar 7 14:42:21 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA61117
for <hackers@postgresql.org>; Tue, 7 Mar 2000 14:42:03 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12SPre-000LEMC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for hackers@postgresql.org; Tue, 7 Mar 2000 13:41:54 -0600 (CST)
Date: Tue, 7 Mar 2000 13:41:54 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Cc: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] CREATE VIEW fix
Message-ID: <20000307134154.D21828@rice.edu>
References: <38C52AEB.87DF5035@alumni.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <38C52AEB.87DF5035@alumni.caltech.edu>;
from lockhart@alumni.caltech.edu on Tue, Mar 07, 2000 at
04:14:35PM +0000

On Tue, Mar 07, 2000 at 04:14:35PM +0000, Thomas Lockhart wrote:

I've got patches to fix the CREATE VIEW command to support SQL92
syntax for result column names, a la

CREATE VIEW (a, b, c) AS SELECT ...

It is an almost trivial fix, requiring the addition of a single field
in the View structure and a few lines of code in analyze.c.

Hmm, couldn't you just rewrite the SELECT d, e, f ... part to use the
AS syntax? I was thinking that both:

CREATE VIEW (a, b, c) AS SELECT d, e, f ...
CREATE VIEW AS SELECT d AS a, e AS b, f AS c ...

should result in the same VIEW being created. But, hey, don't let me
knock already written code!

I'll commit this at the same time I commit support for the SQL92
OVERLAPS operator, which will need an initdb anyway since there are a
few new functions in pg_proc. I believe that we have at least one
other patch coming which will force an initdb anyway, and I'll
coordinate with that.

- Thomas

Excellent: Both changes will help with the NIST test suite I'm (trying)
to run.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

[Charset ISO-8859-1 unsupported, filtering to ASCII...]

Bruce Momjian writes:

Looks very nice, but we can't apply it during beta. Only bug fixes, and
this looks a little tricky. We can try it for 7.1. Maybe you can get
us a 7.0 based patch.

It was me that encouraged him to send in this patch now because Karel and
I are currently talking about redoing the ACL stuff for 7.1.

I considered this a bug and the fix looks pretty straightforward. Perhaps
it should go into 7.0.1?

It will never make it into 7.0.1. Beta is your only chance, and I don't
think it is do-able. It will take a few weeks to get a 7.0 based patch,
and I don't see the reason to add a feature at this time.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Mar 7 18:27:23 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA16903
for <pgsql-hackers@postgresql.org>; Tue, 7 Mar 2000 18:26:42 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA27922;
Tue, 7 Mar 2000 18:25:49 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003072325.SAA27922@candle.pha.pa.us>
Subject: Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
In-Reply-To: <Pine.LNX.4.21.0003040427210.489-100000@localhost.localdomain>
from Peter Eisentraut at "Mar 4, 2000 06:06:37 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 7 Mar 2000 18:25:49 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
Thomas Lockhart <lockhart@alumni.caltech.edu>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Okay, that's the first reasonable argument I've heard in this thread, and
I'll buy it. Since correspondence between internal type names and function
names *is* achievable without hacks we might as well go for this one.

In turn I'm thinking that it might be nice to have a backend function like
format_type(name[, int4]) that formats an internal type and any size
modifier for client consumption, like

format_type('varchar', 8) => "CHARACTER VARYING(8)"
format_type('my type') => "\"my type\""
format_type('numeric', {xxx}) => "NUMERIC(9,2)"

That could put an end to keeping track of backend implementation details
in psql, pg_dump, and friends.

Great idea! psql and pg_dump can use it.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Mar 7 18:37:23 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA20077
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 18:36:29 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA00120;
Tue, 7 Mar 2000 18:35:35 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003072335.SAA00120@candle.pha.pa.us>
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
In-Reply-To: <20000305180951D.t-ishii@sra.co.jp> from Tatsuo Ishii at "Mar 5,
2000 06:09:51 pm"
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Tue, 7 Mar 2000 18:35:35 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I see following in HISTORY:

Disallow DROP TABLE/DROP INDEX inside a transaction block

However, it seems that this is not done with current?

test=# create table t1(i int);
CREATE
test=# begin;
BEGIN
test=# drop table t1;
NOTICE: Caution: DROP TABLE cannot be rolled back, so don't abort now
DROP
test=# end;
COMMIT
test=# \d
No relations found.
--
Tatsuo Ishii

OK, seems it is fixed. I will remove the item.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Mar 7 18:40:23 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA21060
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 18:39:56 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA00290;
Tue, 7 Mar 2000 18:39:24 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003072339.SAA00290@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_pwd trigger to be removed
In-Reply-To: <Pine.LNX.4.21.0003051422190.347-100000@localhost.localdomain>
from Peter Eisentraut at "Mar 5, 2000 02:29:50 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 7 Mar 2000 18:39:24 -0500 (EST)
CC: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset ISO-8859-1 unsupported, filtering to ASCII...]

Because of the problems that were pointed out, I'm inclined to remove the
pg_pwd updating trigger again. I can offer you the non-initdb requiring
variant (just remove the trigger definition in initdb) or the
clean-sweeping one (remove the trigger function from the backend). Okay,
the first one will require some sort of intervention as well, eventually,
but you see the difference.

I think we liked the trigger, but wanted it to activate only on
transaction commit. I think Tom Lane had some ideas on this.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Mar 7 18:41:23 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA21420
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 18:41:02 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA00329;
Tue, 7 Mar 2000 18:40:23 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003072340.SAA00329@candle.pha.pa.us>
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
In-Reply-To: <Pine.LNX.4.21.0003051434090.347-100000@localhost.localdomain>
from Peter Eisentraut at "Mar 5, 2000 02:36:22 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 7 Mar 2000 18:40:23 -0500 (EST)
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset ISO-8859-1 unsupported, filtering to ASCII...]

Tatsuo Ishii writes:

I see following in HISTORY:

Disallow DROP TABLE/DROP INDEX inside a transaction block

However, it seems that this is not done with current?

test=# create table t1(i int);
CREATE
test=# begin;
BEGIN
test=# drop table t1;
NOTICE: Caution: DROP TABLE cannot be rolled back, so don't abort now

Wow, with all due respect, that's pretty sh^H^Hpoor. That's like saying
"Haha, either you commit your transaction or your database is fried." Any
reason that's not an ERROR before anything destructive is done?

I tried it and the ABORT worked, so I have no idea now what is happening
here.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Mar 7 18:50:23 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA24007
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 18:49:54 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA01057;
Tue, 7 Mar 2000 18:48:55 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003072348.SAA01057@candle.pha.pa.us>
Subject: Re: [HACKERS] xlog.c.patch for cygwin port.
In-Reply-To: <003001bf8732$1c3df400$0101010a@magic> from Alexei Zakharov at
"Mar 6, 2000 12:06:27 pm"
To: Alexei Zakharov <A.S.Zakharov@inp.nsk.su>
Date: Tue, 7 Mar 2000 18:48:55 -0500 (EST)
CC: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Applied.

[Charset Windows-1252 unsupported, skipping...]

[Attachment, skipping...]

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Mar 7 18:53:23 2000
Received: from host.kw.igs.net (host.kw.igs.net [216.58.99.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA25021
for <pgsql-hackers@postgresql.org>; Tue, 7 Mar 2000 18:53:14 -0500 (EST)
(envelope-from jimbag@kw.igs.net)
Received: from kw.igs.net (cr930156-a.glph1.on.wave.home.com [24.112.145.20])
by host.kw.igs.net (8.9.3/8.9.2) with ESMTP id SAA10535
for <pgsql-hackers@postgresql.org>; Tue, 7 Mar 2000 18:53:09 -0500 (EST)
(envelope-from jimbag@kw.igs.net)
Sender: jimbag@host.kw.igs.net
Message-ID: <38C59662.2F10991C@kw.igs.net>
Date: Tue, 07 Mar 2000 18:53:06 -0500
From: JB <jimbag@kw.igs.net>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: 'LIKE' enhancement
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all. I'm not subscribed to the list but I thought I'd drop this in
here as a suggestion. There is a thread in GENERAL called '50MB Table'
for those interested. The summary is, I have a 50MB +- table with about
70,000 records which on wich I was doing LIKE selects. It was taking
approx 20 secs to complete the search. The table is something like...

CREATE TABLE info (
lastname char(50),
street_name char(50),
...(etc omitted)
);

CREATE INDEX nx_info1 ON info (lastname);
CREATE INDEX nx_info2 ON info (street_name);

on which I was doing...

SELECT * FROM info WHERE street_name LIKE 'MAIN%';

...this would take about 20 secs to complete. Because the wildness only
happens at the end of the search string, I changed the query to...

SELECT * FROM info WHERE substring( street_name from 1 to 4 ) = 'MAIN';

...this takes under 2 secs. I wrote a piece of code in python to do this
automatically for me but it seems to me that the parser/optimizer could
take a look at this case and re-write the query with the '=' instead of
the 'LIKE'. I've looked through the 'C' code to see where this could
happen but it is too thick for me to sort out with my schedule, so I
thought I'd make the suggestion here.

cheers
jim

--
If everything is coming your way then you're in the wrong lane.

I've even received a mail trying to explain me that update and delete are
the same thing because you can update a record you want to delete but have
no right to, to change its data... of course this is possible, but
nevertheless the record isn't deleted, so update and delete really are two
different things, not to mention you may want to give delete permission
but not insert nor update.

As I told previously in private to Bruce, I won't be able to make this
patch for 7.0 until a week or two, so if someone do it before (please do,
because you better know postgresql code than me, so you'll make less
mistakes), just tell me because I don't really want to duplicate the
effort.

bye,

PS: could someone explain me what "tricky" means ?

Tricky means not based on 7.0, and it mucks with the internals, and that
it may require an initdb.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Mar 7 19:08:24 2000
Received: from clio.trends.ca (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA28320;
Tue, 7 Mar 2000 19:07:23 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id TAA08920;
Tue, 7 Mar 2000 19:00:54 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id SAA22709;
Tue, 7 Mar 2000 18:59:53 -0500 (EST)
To: Kyle Bateman <kyle@actarg.com>
cc: pgsql-sql@postgresql.org, pgsql-hackers@postgresql.org
Subject: Casts in 7.0 vs 6.5 (was Re: [SQL] 7.0beta bug (or feature)?)
In-reply-to: <38C0022D.B30A7536@actarg.com>
References: <38C0022D.B30A7536@actarg.com>
Comments: In-reply-to Kyle Bateman <kyle@actarg.com>
message dated "Fri, 03 Mar 2000 11:19:25 -0700"
Date: Tue, 07 Mar 2000 18:59:53 -0500
Message-ID: <22705.952473593@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Kyle Bateman <kyle@actarg.com> writes:

This function would load OK in 6.5 but doesn't work in 7.0beta1:

create function date_week(date) returns text as '
select date_week($1::text);
' LANGUAGE 'sql';

ERROR: No such function 'date_week' with the specified attributes

... apparently, the parser does not recognize
the fact that a cast is present and tries to look for an existing
function date_week(date) instead of date_week(text).

Yup, 7.0beta1 is missing a couple of lines of code needed to handle
casts applied to function parameters. Thanks for catching that.
I have patched current CVS sources; tonight's snapshot should have
the fix.

It looks like either there is a problem in the parser with casting, or
there is a new way of doing things I should adapt to.

7.0 currently is a little snippier about casts than prior releases were;
it wants the cast to equate directly to an available conversion.
So what I'm getting from your example now is

regression=# create function date_week(date) returns text as '
regression'# select date_week($1::text);
regression'# ' LANGUAGE 'sql';
ERROR: Cannot cast type 'date' to 'text'

because there isn't a text(date) function. But there is a
text(timestamp) function, and a timestamp(date) function,
so this works:

regression=# create function date_week(date) returns text as '
regression'# select date_week($1::timestamp::text);
regression'# ' LANGUAGE 'sql';
CREATE

6.5 would do the intermediate conversion to timestamp (then called
datetime) silently, but 7.0 won't. Note that both versions will
happily take
select date_week(text($1));
and interpolate the intermediate conversion step as part of resolving
the overloaded function name text(). 7.0 is only picky about
conversions written as casts.

I am not sure whether this should be regarded as a bug or a feature.
On the one hand you could argue that ambiguous casts are a bad thing,
but on the other hand, if text(foo) works, why shouldn't foo::text work?

One thing to realize while considering whether to change this is that if
we generalize the behavior of casts, we may also affect the behavior of
implicit casts, such as the one applied to convert supplied data in an
INSERT or UPDATE to the target column type. This could result in loss
of error detection capability. Currently, both 6.5 and 7.0 do this:

regression=# create table foo(f1 text);
CREATE
regression=# insert into foo values('now'::date);
ERROR: Attribute 'f1' is of type 'text' but expression is of type 'date'
You will need to rewrite or cast the expression

but if we allow datevalue::text to work, then (barring still more
pushups in the code) the above will be accepted. Should it be?

Comments anyone?

regards, tom lane

From bouncefilter Tue Mar 7 19:07:26 2000
Received: from clio.trends.ca (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA28309
for <pgsql-hackers@postgresql.org>; Tue, 7 Mar 2000 19:07:17 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: from candle.pha.pa.us (s5-03.ppp.op.net [209.152.195.67])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id TAA08912
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 19:00:49 -0500 (EST)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA03639;
Tue, 7 Mar 2000 19:00:16 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003080000.TAA03639@candle.pha.pa.us>
Subject: Re: [HACKERS] Proposal for Grand Unified Configuration scheme
In-Reply-To: <Pine.LNX.4.21.0003061512190.362-100000@localhost.localdomain>
from Peter Eisentraut at "Mar 6, 2000 04:59:57 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 7 Mar 2000 19:00:16 -0500 (EST)
CC: PostgreSQL Development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset ISO-8859-1 unsupported, filtering to ASCII...]

I have (almost) nothing to do for about 3 weeks, so I thought I'd get
started on some stuff for next time around.

The idea here is to unify all the various configuration settings into one
coherent scheme. This would include:

* pg_options
* pg_geqo
* postmaster.opts
* Most of the postgres and postmaster command line options
* (almost?) everything you can use SET on
* All the temporary solutions via server side environment variables

Clearly has to be done.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Mar 7 19:04:23 2000
Received: from host.kw.igs.net (host.kw.igs.net [216.58.99.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA27543
for <pgsql-hackers@postgresql.org>; Tue, 7 Mar 2000 19:04:19 -0500 (EST)
(envelope-from jimbag@kw.igs.net)
Received: from kw.igs.net (cr930156-a.glph1.on.wave.home.com [24.112.145.20])
by host.kw.igs.net (8.9.3/8.9.2) with ESMTP id TAA11425
for <pgsql-hackers@postgresql.org>; Tue, 7 Mar 2000 19:04:19 -0500 (EST)
(envelope-from jimbag@kw.igs.net)
Sender: jimbag@host.kw.igs.net
Message-ID: <38C59900.2A4469C8@kw.igs.net>
Date: Tue, 07 Mar 2000 19:04:16 -0500
From: JB <jimbag@kw.igs.net>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: 'LIKE' enhancement suggestion
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have a 50MB +- table with about 70,000 records which on which I was
doing LIKE selects. It was taking approx 20 secs to complete the search.
The table is something like...

CREATE TABLE info (
lastname char(50),
street_name char(50),
...(etc omitted)
);

CREATE INDEX nx_info1 ON info (lastname);
CREATE INDEX nx_info2 ON info (street_name);

on which I was doing...

SELECT * FROM info WHERE street_name LIKE 'MAIN%';

...this would take about 20 secs to complete. Because the wildness only
happens at the end of the search string, I changed the query to...

SELECT * FROM info WHERE substring( street_name from 1 to 4 ) = 'MAIN';

...this takes under 2 secs. I wrote a piece of code in python to do this
automatically for me but it seems to me that the parser/optimizer could
take a look at this case and re-write the query with the '=' instead of
the 'LIKE'. I've looked through the 'C' code to see where this could
happen but it is too thick for me to sort out with my schedule, so I
thought I'd make the suggestion here.

cheers
jim
--
If everything is coming your way then you're in the wrong lane.

From bouncefilter Tue Mar 7 19:10:24 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA29108
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 19:10:06 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA04181;
Tue, 7 Mar 2000 19:09:21 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003080009.TAA04181@candle.pha.pa.us>
Subject: Re: [HACKERS] sqgfault on initdb with current CVS
In-Reply-To: <38C49097.94F026E7@alumni.caltech.edu> from Thomas Lockhart at
"Mar 7, 2000 05:16:07 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Tue, 7 Mar 2000 19:09:21 -0500 (EST)
CC: Bruce Momjian <maillist@candle.pha.pa.us>,
Tatsuo Ishii <t-ishii@sra.co.jp>, reedstrm@wallace.ece.rice.edu,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug

For some reason, current does not seem to allow "." in the
$PGDATA. I'm no sure why this happens at all. I guess it intends to
inhibit "./" or "../" for a security reason? If so, that would be
apparently an overkill.

Bruce, can you add this item to the "must fix" list for the 7.0
release (hint hint - is it time to start that list?? ;)

Also, please add to the same list:

o implement the OVERLAPS date/time operator from SQL92 (Thomas)
o support TIME WITH TIME ZONE timezones in literals (Thomas)
o add support for full POSIX time zone specification (Thomas)

We don't have any must fixes for 7.0 yet. Why are these worthy?

The POSIX time zone stuff is already in there, new for this release,
but needs to be polished to work with TZs away from GMT. The OVERLAPS
stuff is coded and being tested now; it just adds a few functions and
a bit of gram.y syntax.

Initdb required. You better get an OK from Marc.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Mar 7 19:14:24 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA30209
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 19:13:57 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA04387;
Tue, 7 Mar 2000 19:13:06 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003080013.TAA04387@candle.pha.pa.us>
Subject: Re: [HACKERS] xlog.c.patch for cygwin port.
In-Reply-To: <38C492C232E.8E0EYUTAKA@s34gway.s34.co.jp> from yutaka tanida at
"Mar 7, 2000 02:25:22 pm"
To: yutaka tanida <yutaka@marin.or.jp>
Date: Tue, 7 Mar 2000 19:13:06 -0500 (EST)
CC: Alexei Zakharov <A.S.Zakharov@inp.nsk.su>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

This looks interesting. We could remove some of our ifwin cruft.

---------------------------------------------------------------------------

On Mon, 6 Mar 2000 12:06:27 +0600
"Alexei Zakharov" <A.S.Zakharov@inp.nsk.su> wrote:

I suggest a following patch. BTW the situation appeared before,
see hba.c, pqcomm.c and others.

I propose another patch, against src/include/port/win.h.
If this patch is applied, #ifdef with open() such as following is no
more needed.

--
#ifndef __CYGWIN__
fd=open(path,flags,mode);
#else
fd=open(path,flags | O_BINARY,mode);
#endif
--

Comments?

--
Yutaka tanida / S34 Co., Ltd.
tanida@s34.co.jp (Office)
yutaka@marin.or.jp(Private, or if you *HATE* Microsoft Outlook)

*** win.h.orig	Thu Feb 10 17:00:14 2000
--- win.h	Tue Mar 07 14:07:21 2000
***************
*** 10,15 ****
--- 10,35 ----
  #define USE_POSIX_TIME
  #define HAVE_INT_TIMEZONE		/* has int _timezone */

+ /* open() must use with O_BINARY flag */
+ 
+ #include<stdarg.h>
+ #include<sys/fcntl.h>
+ 
+ static __inline int pg_cygwin_open(const char *pathname,int flags,...) {
+     va_list va;
+ 	mode_t mode;
+ 	if(flags | O_CREAT) {
+         va_start(va,flags);
+         mode=va_arg(va,int);
+         va_end(va);
+     	return open(pathname,flags | O_BINARY,mode);
+ 	}else{
+     	return open(pathname,flags | O_BINARY);
+ 	}
+ }
+ 
+ #define open pg_cygwin_open
+ 
  #include <cygwin/version.h>
  #if (CYGWIN_VERSION_API_MAJOR >= 0) && (CYGWIN_VERSION_API_MINOR >= 8)
  #define sys_nerr _sys_nerr

************

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Mar 7 19:15:24 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA30687
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 19:15:19 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA22799;
Tue, 7 Mar 2000 19:15:11 -0500 (EST)
To: bhirt@mobygames.com
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Optimizer badness in 7.0 beta
In-reply-to: <20000305032655.A29257@loopy.berkhirt.com>
References: <20000305032655.A29257@loopy.berkhirt.com>
Comments: In-reply-to Brian Hirt <bhirt@mobygames.com>
message dated "Sun, 05 Mar 2000 03:26:55 -0600"
Date: Tue, 07 Mar 2000 19:15:10 -0500
Message-ID: <22796.952474510@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Brian Hirt <bhirt@mobygames.com> writes:

-- PG 7.0 --
NOTICE: QUERY PLAN:

Sort (cost=383940.72..383940.72 rows=905 width=59)
-> Seq Scan on game (cost=0.00..383896.28 rows=905 width=59)
SubPlan
-> Unique (cost=0.00..808.88 rows=0 width=4)
-> Index Scan using game_developer_game_index on game_developer (cost=0.00..808.87 rows=4 width=4)

There's something very strange about this query plan --- why is the
estimated cost of the indexscan so high? If I do, say,

regression=# explain select distinct * from tenk1 where unique1 < 3;
NOTICE: QUERY PLAN:

Unique (cost=3.22..3.34 rows=0 width=148)
-> Sort (cost=3.22..3.22 rows=3 width=148)
-> Index Scan using tenk1_unique1 on tenk1 (cost=0.00..3.19 rows=3 width=148)

The tenk1 table from the regression database is only 10K rows, versus
15K in your table, but still I'd expect costs not a heck of a lot higher
than one page fetch per tuple retrieved. How is it coming up with a
cost of 800 to retrieve 4 tuples?

Could I trouble you for the exact declarations of the tables and indices
involved here? Also, what plan do you get from 7.0 if you do

set enable_indexscan = 'off';

before the EXPLAIN?

regards, tom lane

From bouncefilter Tue Mar 7 19:19:24 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA31719
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 19:18:46 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA04546;
Tue, 7 Mar 2000 19:17:33 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003080017.TAA04546@candle.pha.pa.us>
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
In-Reply-To: <19326.952415629@sss.pgh.pa.us> from Tom Lane at "Mar 7,
2000 02:53:49 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 7 Mar 2000 19:17:33 -0500 (EST)
CC: Mike Mascari <mascarm@mascari.com>, Peter Eisentraut <peter_e@gmx.net>,
Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

BTW, we are not *that* far from being able to roll back a DROP TABLE.
The only thing that's really needed is for everyone to take a deep
breath and let go of the notion that table files ought to be named
after the tables. If we named table files after the OIDs of their
tables, then rollback-able DROP or RENAME TABLE would be pretty
straightforward. If you don't recall why this is, consult the
pghackers archives...

The oid will be appended to the base file name.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Mar 7 19:19:24 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA31658
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 19:18:42 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA04729;
Tue, 7 Mar 2000 19:17:51 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003080017.TAA04729@candle.pha.pa.us>
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
In-Reply-To: <20000307170643S.t-ishii@sra.co.jp> from Tatsuo Ishii at "Mar 7,
2000 05:06:43 pm"
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Tue, 7 Mar 2000 19:17:51 -0500 (EST)
CC: tgl@sss.pgh.pa.us, mascarm@mascari.com, peter_e@gmx.net,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

So what was the conclusion for 7.0?

Disallow DROP TABLE/DROP INDEX inside a transaction block

We should remove above from HISTORY, no?

Yes removed.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Mar 7 19:22:24 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA32956
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 19:22:17 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA22868;
Tue, 7 Mar 2000 19:22:14 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] pg_pwd trigger to be removed
In-reply-to: <Pine.LNX.4.21.0003051422190.347-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0003051422190.347-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Sun, 05 Mar 2000 14:29:50 +0100"
Date: Tue, 07 Mar 2000 19:22:14 -0500
Message-ID: <22865.952474934@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

Because of the problems that were pointed out, I'm inclined to remove the
pg_pwd updating trigger again.

Actually, what I'd like to see is a fix that makes the trigger robust.
Maybe that's too much work for 7.0.

If we had a robust solution for this problem, then we could apply the
same method to export a flat-file equivalent of pg_database, which could
be read during backend startup. That would allow us to get rid of some
incredibly grotty (and not 100% reliable) code that tries to read
pg_database before the transaction management code has been fired up :-(

My new take on the situation is actually that there shouldn't be a reason
to tinker with the systems catalogs period.

Maybe so, but we still could make good use of an end-of-transaction
trigger to update pg_pwd from pg_shadow. Right now, rollback of a
pg_shadow update doesn't really work right even if you did it via
CREATE/ALTER USER.

regards, tom lane

From bouncefilter Tue Mar 7 19:32:24 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA36577
for <pgsql-hackers@postgresql.org>; Tue, 7 Mar 2000 19:32:13 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA22978;
Tue, 7 Mar 2000 19:32:10 -0500 (EST)
To: JB <jimbag@kw.igs.net>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 'LIKE' enhancement suggestion
In-reply-to: <38C59900.2A4469C8@kw.igs.net>
References: <38C59900.2A4469C8@kw.igs.net>
Comments: In-reply-to JB <jimbag@kw.igs.net>
message dated "Tue, 07 Mar 2000 19:04:16 -0500"
Date: Tue, 07 Mar 2000 19:32:10 -0500
Message-ID: <22975.952475530@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

JB <jimbag@kw.igs.net> writes:

SELECT * FROM info WHERE street_name LIKE 'MAIN%';

...this would take about 20 secs to complete. Because the wildness only
happens at the end of the search string, I changed the query to...

SELECT * FROM info WHERE substring( street_name from 1 to 4 ) = 'MAIN';

...this takes under 2 secs.

This makes no sense to me at all. The latter query should be far
slower, because AFAIK there is no optimization for it, whereas there is
an optimization for "foo LIKE 'bar%'".

What version are you running, and what plan does EXPLAIN show for
each of these queries?

regards, tom lane

From bouncefilter Tue Mar 7 19:56:24 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA43888
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 19:55:31 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA23147;
Tue, 7 Mar 2000 19:55:17 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, Tatsuo Ishii <t-ishii@sra.co.jp>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
In-reply-to: <200003072340.SAA00329@candle.pha.pa.us>
References: <200003072340.SAA00329@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Tue, 07 Mar 2000 18:40:23 -0500"
Date: Tue, 07 Mar 2000 19:55:17 -0500
Message-ID: <23144.952476917@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I tried it and the ABORT worked, so I have no idea now what is happening
here.

Is the table file still there after the ABORT? If not, it won't work
for long...

regards, tom lane

From bouncefilter Tue Mar 7 20:05:24 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA46492
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 20:04:41 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA23180;
Tue, 7 Mar 2000 20:01:16 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: yutaka tanida <yutaka@marin.or.jp>,
Alexei Zakharov <A.S.Zakharov@inp.nsk.su>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] xlog.c.patch for cygwin port.
In-reply-to: <200003080013.TAA04387@candle.pha.pa.us>
References: <200003080013.TAA04387@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Tue, 07 Mar 2000 19:13:06 -0500"
Date: Tue, 07 Mar 2000 20:01:16 -0500
Message-ID: <23176.952477276@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

This looks interesting. We could remove some of our ifwin cruft.

I have been thinking for quite some time that most of the CYGWIN32
ifdefs represent very poor programming. Instead of zillions of

#ifndef __CYGWIN32__
fd = open(filename, O_RDONLY, 0666);
#else
fd = open(filename, O_RDONLY | O_BINARY, 0666);
#endif

we should have in one include file something like

#ifndef __CYGWIN32__
#define OPEN_FLAGS_READ O_RDONLY
#define OPEN_FLAGS_WRITE O_WRONLY
// etc for the combinations we need
#else
#define OPEN_FLAGS_READ (O_RDONLY | O_BINARY)
#define OPEN_FLAGS_WRITE (O_WRONLY | O_BINARY)
// etc
#endif

and then the body of the code would have

fd = open(filename, OPEN_FLAGS_READ, 0666);

and no ifdef. This would also provide a single place to tweak open()
flags for other platforms, whereas the existing method is exactly zero
help for any non-CYGWIN platform that wants to add O_BINARY ...

regards, tom lane

From bouncefilter Tue Mar 7 20:10:24 2000
Received: from thelab.hub.org (nat195.52.mpoweredpc.net [142.177.195.52])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA47720
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 20:09:36 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id VAA11004;
Tue, 7 Mar 2000 21:08:27 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 7 Mar 2000 21:08:27 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Bruce Momjian <maillist@candle.pha.pa.us>,
Tatsuo Ishii <t-ishii@sra.co.jp>, reedstrm@wallace.ece.rice.edu,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] sqgfault on initdb with current CVS
In-Reply-To: <200003080009.TAA04181@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0003072107460.591-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 7 Mar 2000, Bruce Momjian wrote:

wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug

For some reason, current does not seem to allow "." in the
$PGDATA. I'm no sure why this happens at all. I guess it intends to
inhibit "./" or "../" for a security reason? If so, that would be
apparently an overkill.

Bruce, can you add this item to the "must fix" list for the 7.0
release (hint hint - is it time to start that list?? ;)

Also, please add to the same list:

o implement the OVERLAPS date/time operator from SQL92 (Thomas)
o support TIME WITH TIME ZONE timezones in literals (Thomas)
o add support for full POSIX time zone specification (Thomas)

We don't have any must fixes for 7.0 yet. Why are these worthy?

The POSIX time zone stuff is already in there, new for this release,
but needs to be polished to work with TZs away from GMT. The OVERLAPS
stuff is coded and being tested now; it just adds a few functions and
a bit of gram.y syntax.

Initdb required. You better get an OK from Marc.

Go for it ... no INITDBs after our first release candidate, but if these
are must-have's, we've only done one Beta1, so get it into Beta2...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Mar 7 20:15:32 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA48689
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 20:14:29 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA23213;
Tue, 7 Mar 2000 20:13:54 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Mike Mascari <mascarm@mascari.com>, Peter Eisentraut <peter_e@gmx.net>,
Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
In-reply-to: <200003080017.TAA04546@candle.pha.pa.us>
References: <200003080017.TAA04546@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Tue, 07 Mar 2000 19:17:33 -0500"
Date: Tue, 07 Mar 2000 20:13:53 -0500
Message-ID: <23210.952478033@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:

BTW, we are not *that* far from being able to roll back a DROP TABLE.
The only thing that's really needed is for everyone to take a deep
breath and let go of the notion that table files ought to be named
after the tables. If we named table files after the OIDs of their
tables, then rollback-able DROP or RENAME TABLE would be pretty
straightforward. If you don't recall why this is, consult the
pghackers archives...

The oid will be appended to the base file name.

If we do it that way, then RENAME TABLE will be kinda complicated...
not impossible, but is it worth it?

regards, tom lane

From bouncefilter Tue Mar 7 20:21:27 2000
Received: from thelab.hub.org (nat195.52.mpoweredpc.net [142.177.195.52])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA50679
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 20:20:57 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id VAA18129;
Tue, 7 Mar 2000 21:19:09 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 7 Mar 2000 21:19:09 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
yutaka tanida <yutaka@marin.or.jp>,
Alexei Zakharov <A.S.Zakharov@inp.nsk.su>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] xlog.c.patch for cygwin port.
In-Reply-To: <23176.952477276@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0003072118401.591-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Sounds like a *great* bug fix to me ... if you "have better things to do",
I can tackle it ...

On Tue, 7 Mar 2000, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

This looks interesting. We could remove some of our ifwin cruft.

I have been thinking for quite some time that most of the CYGWIN32
ifdefs represent very poor programming. Instead of zillions of

#ifndef __CYGWIN32__
fd = open(filename, O_RDONLY, 0666);
#else
fd = open(filename, O_RDONLY | O_BINARY, 0666);
#endif

we should have in one include file something like

#ifndef __CYGWIN32__
#define OPEN_FLAGS_READ O_RDONLY
#define OPEN_FLAGS_WRITE O_WRONLY
// etc for the combinations we need
#else
#define OPEN_FLAGS_READ (O_RDONLY | O_BINARY)
#define OPEN_FLAGS_WRITE (O_WRONLY | O_BINARY)
// etc
#endif

and then the body of the code would have

fd = open(filename, OPEN_FLAGS_READ, 0666);

and no ifdef. This would also provide a single place to tweak open()
flags for other platforms, whereas the existing method is exactly zero
help for any non-CYGWIN platform that wants to add O_BINARY ...

regards, tom lane

************

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Mar 7 20:25:29 2000
Received: from host.kw.igs.net (host.kw.igs.net [216.58.99.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA51998
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 20:25:22 -0500 (EST)
(envelope-from jimbag@kw.igs.net)
Received: from kw.igs.net (cr930156-a.glph1.on.wave.home.com [24.112.145.20])
by host.kw.igs.net (8.9.3/8.9.2) with ESMTP id UAA17248;
Tue, 7 Mar 2000 20:24:07 -0500 (EST)
(envelope-from jimbag@kw.igs.net)
Sender: jimbag@host.kw.igs.net
Message-ID: <38C5ABB3.28314EB7@kw.igs.net>
Date: Tue, 07 Mar 2000 20:24:03 -0500
From: JB <jimbag@kw.igs.net>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] 'LIKE' enhancement suggestion
References: <38C59900.2A4469C8@kw.igs.net> <22975.952475530@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm running 6.5.2 on RH6.1, 128mb ram, 27gb, P350. I don't understand
this either so please excuse my ignorance. I looked up EXPLAIN and
here's what came out...

---[snip]---
#!/bin/sh
psql -c "EXPLAIN SELECT * FROM info WHERE substring(stname from 1 for 4)
= 'MAIN';"
time psql -c "SELECT * FROM info WHERE substring(stname from 1 for 4) =
'MAIN';"

psql -c "EXPLAIN SELECT * FROM info WHERE stname LIKE 'MAIN%';"
time psql -c "SELECT * FROM info WHERE stname LIKE 'MAIN%';"
---[snip]---

outputs...

Seq Scan on info (cost=3829.93 rows=15454 width=420)

0.01user 0.01system 0:00.72elapsed 2%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (198major+25minor)pagefaults 0swaps

Index Scan using nx_info1 on info (cost=1531.12 rows=30 width=420)

0.01user 0.01system 0:00.64elapsed 3%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (198major+25minor)pagefaults 0swaps

Obviously the numbers don't support me. I'm quite confused. I was told
that the engine didn't use indexes with 'LIKE' by someone equally
informed as I, and thus the 'substring' change. This worked remarkably
faster so I assumed it to be true. Apparently it is not. There must be
something with the bigger system that I need to look into (mem usage,
etc). My apologies for chewing up bandwidth.

jb

Tom Lane wrote:

JB <jimbag@kw.igs.net> writes:

SELECT * FROM info WHERE street_name LIKE 'MAIN%';

...this would take about 20 secs to complete. Because the wildness only
happens at the end of the search string, I changed the query to...

SELECT * FROM info WHERE substring( street_name from 1 to 4 ) = 'MAIN';

...this takes under 2 secs.

This makes no sense to me at all. The latter query should be far
slower, because AFAIK there is no optimization for it, whereas there is
an optimization for "foo LIKE 'bar%'".

What version are you running, and what plan does EXPLAIN show for
each of these queries?

regards, tom lane

************

--
If everything is coming your way then you're in the wrong lane.

From bouncefilter Tue Mar 7 20:29:25 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA52905
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 20:28:40 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA23288
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 20:28:02 -0500 (EST)
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] library policy question
In-reply-to: <Pine.BSF.4.21.0003071906140.591-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0003071906140.591-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Tue, 07 Mar 2000 19:06:24 -0400"
Date: Tue, 07 Mar 2000 20:28:02 -0500
Message-ID: <23285.952478882@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

The Hermit Hacker <scrappy@hub.org> writes:

On Tue, 7 Mar 2000, Thomas Lockhart wrote:

7.0 would be a good time to do that if we were gonna do it. Comments?

Yup.

Ditto ...

OK, I'll take a look at doing it later this week.

regards, tom lane

From bouncefilter Tue Mar 7 20:31:25 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA53722
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Mar 2000 20:31:01 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA06414;
Tue, 7 Mar 2000 20:30:17 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003080130.UAA06414@candle.pha.pa.us>
Subject: Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
In-Reply-To: <38C52478.42D74BAF@alumni.caltech.edu> from Thomas Lockhart at
"Mar 7, 2000 03:47:04 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Tue, 7 Mar 2000 20:30:17 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

format_type(name[, int4]) that formats an internal type and any size
modifier for client consumption, like
format_type('varchar', 8) => "CHARACTER VARYING(8)"
format_type('my type') => "\"my type\""
format_type('numeric', {xxx}) => "NUMERIC(9,2)"

Ooh, that *is* a good idea (though the exact name of the function may
evolve)! Sorry I missed seeing it in Peter's earlier postings.

Funny how we can go for years banging our heads on an issue and have
something like this (ie a good idea on the subject) pop up out of the
blue.

Presumably we would include a function taking the conversion the other
direction too...

Not sure it is really needed. We already to the translation in gram.y.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Mar 7 20:33:25 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA54296
for <hackers@postgreSQL.org>; Tue, 7 Mar 2000 20:32:57 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA06460;
Tue, 7 Mar 2000 20:32:18 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003080132.UAA06460@candle.pha.pa.us>
Subject: Re: [HACKERS] CREATE VIEW fix
In-Reply-To: <38C52AEB.87DF5035@alumni.caltech.edu> from Thomas Lockhart at
"Mar 7, 2000 04:14:35 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Tue, 7 Mar 2000 20:31:46 -0500 (EST)
CC: Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I've got patches to fix the CREATE VIEW command to support SQL92
syntax for result column names, a la

CREATE VIEW (a, b, c) AS SELECT ...

It is an almost trivial fix, requiring the addition of a single field
in the View structure and a few lines of code in analyze.c.

I'll commit this at the same time I commit support for the SQL92
OVERLAPS operator, which will need an initdb anyway since there are a
few new functions in pg_proc. I believe that we have at least one
other patch coming which will force an initdb anyway, and I'll
coordinate with that.

Sounds good. We may have some people running production on 7.0 beta.
They will need to use pg_upgrade.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Mar 7 20:36:32 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA55028;
Tue, 7 Mar 2000 20:35:39 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA06675;
Tue, 7 Mar 2000 20:35:01 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003080135.UAA06675@candle.pha.pa.us>
Subject: Re: [HACKERS] library policy question
In-Reply-To: <20377.952446844@sss.pgh.pa.us> from Tom Lane at "Mar 7,
2000 11:34:04 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 7 Mar 2000 20:35:01 -0500 (EST)
CC: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hmm, we do have a bit of a problem here. While PQconnectdb can be
replaced by PQsetdb to avoid the concurrency issue, there is no
thread-safe equivalent for the new routines
PQconnectStart/PQconnectPoll. That may not matter much, because
probably you would only need those in a single-threaded environment,
but it's still kinda ugly. In any case it'd be a lot nicer to be
able to say "libpq is thread safe" rather than "almost thread safe".

At one point we had discussed going ahead and breaking compatibility
in order to get rid of the static PQconninfoOption array. It wouldn't
be a big change in the API: we'd only need to make PQconndefaults return
a malloc'd array instead of a static. That probably wouldn't really
break any existing code, just create a small memory leak in applications
that didn't know to free the result when they were done with it. My bet
is that very few apps use PQconndefaults anyway.

7.0 would be a good time to do that if we were gonna do it. Comments?

Seems like a good time to do it.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Jerome ALET writes:

[censored stuff snipped]

Don't even expect me to rewrite this patch for 7.0, because it's not my
problem anymore, it's yours (and other postgresql users') !

I don't think that personal attacks like this are warranted. Tom points
out that this is a relatively big code change by an "outsider" during beta
which would also require users to re-initdb their database. It's an
unfortunate situation but if a plurality of core developers says that this
would be too much potential burden during beta you have to accept it. You
are free to publish your patch via other mechanisms if you like, or
contribute it to 7.1.

And patches based on older versions can't be used in general.

At least you should document this security problem.

Agreed.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Wed Mar 8 19:38:28 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA95154
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Mar 2000 19:37:53 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id JAA00039; Thu, 09 Mar 2000 09:37:04 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>,
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] DROP TABLE inside a transaction block
Date: Thu, 9 Mar 2000 09:43:35 +0900
Message-ID: <000001bf8960$8093d160$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <200003082324.SAA07123@candle.pha.pa.us>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Bruce Momjian

Looked like it was going to be very simple: the RelationGetRelationName
and RelationGetPhysicalRelationName macros encapsulate access to the
(relation)->rd_rel->relname structure member pretty effectively (thanks
to Bruce's temp. relation work, I presume)

Yes.

As a first crack, I decided to use the oid for the filename,

just because

it simplified the chamges to the Macro, and there was already

an oidout()

builtin that'd do the palloc for me ;-)

I object to this proposal.

I have been suspicious why mapping algorithm from relations
to the relation file names is needed for existent relations.
This should be changed first.

And pluaral relation file names are needed for a relation oid/relname.
Why do you prefer fixed mapping oid/relname --> relation file name ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Wed Mar 8 20:05:28 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA26391
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Mar 2000 20:05:10 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA06771;
Wed, 8 Mar 2000 20:04:48 -0500 (EST)
To: Ed Loehr <eloehr@austin.rr.com>
cc: pghackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Transaction abortions & recovery handling
In-reply-to: <38C6ECA5.AA30DE1@austin.rr.com>
References: <38C68B96.909FF724@austin.rr.com> <26543.952545263@sss.pgh.pa.us>
<38C6ECA5.AA30DE1@austin.rr.com>
Comments: In-reply-to Ed Loehr <eloehr@austin.rr.com>
message dated "Wed, 08 Mar 2000 18:13:25 -0600"
Date: Wed, 08 Mar 2000 20:04:48 -0500
Message-ID: <6768.952563888@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Ed Loehr <eloehr@austin.rr.com> writes:

Any suggestions on how I might handle this?

Er ... run 7.0beta ?

Based on recent threads on this list, I have the
impression that 7.0beta is not quite ready for production.

A fair objection, since in fact it isn't. Moving to 7 now will probably
cost you at least one extra dump/initdb/reload cycle, since we are
likely to force another initdb before final release. However, if the
alternative is continuing to get bit by a 6.5 bug, it seems to me that
being an early adopter of 7.0 is not such a bad choice.

I wouldn't actually suggest picking up 7.0beta1 at this point, since
we've fixed a number of flaws since then; the latest nightly snapshot
would be better. Or you might want to wait for 7.0beta2, which should
be out in a day or two.

regards, tom lane

From bouncefilter Wed Mar 8 20:03:28 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA25895
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Mar 2000 20:02:40 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA29020;
Thu, 9 Mar 2000 10:02:37 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-22 [133.137.84.22])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id KAA03807;
Thu, 9 Mar 2000 10:02:35 +0900
To: zakkr@zf.jcu.cz
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] regex (from TODO)
In-Reply-To: <Pine.LNX.3.96.1000308165759.14462D-100000@ara.zf.jcu.cz>
References: <Pine.LNX.3.96.1000308165759.14462D-100000@ara.zf.jcu.cz>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000309101011B.t-ishii@sra.co.jp>
Date: Thu, 09 Mar 2000 10:10:11 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 30

In the PostgreSQL TODO is "Get faster regex() code from Henry Spencer..".

I look at current available regex used (a example) in apache, php, .etc. But
if I look at changes (via diff) between PostgreSQL's regex and more new
regex in PHP4 it is very same. A differentions are that in new regex code
are all values marks as 'register' and this new regex not support MULTIBYTE.

Actually Henry has never supported MULTIBYTE:-) We modified his code
so that we could support it.

It is without any relevant changes (or 'register' is really fastly?).

I vaguely recall that we decided that 'register' did nothing good with
modern compilers, and it'd be better to let the optimizer determine
what variables should be assigned to registers.

What means TODO?

That means "get faster code from Henry and modify it if it does not
support MULTIBYTE" -- I guess.

The PG's regex use malloc -- why not MemoryContext?

Probably because the regex caches the results of regcomp in a static
area which points to a malloced memory allocated while compiling a
regular expression. However, for the regexec stage we might be able to
use palloc instead of malloc. I'm not sure if this would result in a
any better performance, though.
--
Tatsuo Ishii

From bouncefilter Wed Mar 8 21:02:30 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA36845
for <pgsql-hackers@postgresql.org>; Wed, 8 Mar 2000 21:01:41 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA08228;
Wed, 8 Mar 2000 21:00:56 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003090200.VAA08228@candle.pha.pa.us>
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
In-Reply-To: <20000308182220.A31129@rice.edu> from "Ross J. Reedstrom" at "Mar
8, 2000 06:22:20 pm"
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Date: Wed, 8 Mar 2000 21:00:56 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Most problems where code that used RelationGetPhysicalRelationName
when they it should use RelationGetRelationName. In several cases,
the code assumed RelationGetPhysicalRelationName handed them a
pointer to rd_rel->relname, which they copy into! I substituted
RelationGetRelationName for all these cases.

Please send in a patch on those if they need to be corrected, OK?

Once I'm sure it's the Right Thing To Do, I will. That's probably
the only clean part of the ugly hack I've done so far.

I was just really interested in places where
RelationGetPhysicalRelationName() and RelationGetRelationName() where
called incorrectly. That can go into 7.0.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Wed Mar 8 23:22:31 2000
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA72371
for <pgsql-hackers@postgresql.org>; Wed, 8 Mar 2000 23:21:36 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.93.58.117]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Wed, 8 Mar 2000 22:10:50 -0600
Sender: ed
Message-ID: <38C72778.66B02C85@austin.rr.com>
Date: Wed, 08 Mar 2000 22:24:24 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pghackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Transaction abortions & recovery handling
References: <38C68B96.909FF724@austin.rr.com> <26543.952545263@sss.pgh.pa.us>
<38C6ECA5.AA30DE1@austin.rr.com> <6768.952563888@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Ed Loehr <eloehr@austin.rr.com> writes:

Any suggestions on how I might handle this?

Er ... run 7.0beta ?

Based on recent threads on this list, I have the
impression that 7.0beta is not quite ready for production.

A fair objection, since in fact it isn't. [snip] However, if the
alternative is continuing to get bit by a 6.5 bug, it seems to me that
being an early adopter of 7.0 is not such a bad choice.

Agreed, if that is in fact my only alternative. Fortunately, this
showstopper bug shows up infrequently (it's been a month or two since
the last bite). I'm still hoping to avoid the bleeding edge on this
production system.

Is there any reasonably straight-forward means to allowing additional
queries within the same transaction after I get an ERROR?

Regards,
Ed Loehr

From bouncefilter Thu Mar 9 00:33:31 2000
Received: from sapphire.albourne.com (sapphire.albourne.com [195.212.241.227])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA87547
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Mar 2000 00:32:34 -0500 (EST)
(envelope-from a.joubert@albourne.com)
Received: from albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.8/MAPS) with ESMTP
id HAA19091
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Mar 2000 07:32:32 +0200 (EET)
Sender: a.joubert@albourne.com
Message-ID: <38C73715.47C2E84D@albourne.com>
Date: Thu, 09 Mar 2000 07:31:01 +0200
From: Adriaan Joubert <a.joubert@albourne.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgresql <pgsql-hackers@postgreSQL.org>
Subject: Unrecognised machine in 7.0beta1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

The configuration script does not recognise 'alphaev6-dec-osf4.0f' as
a valid machine/OS combination. I've
hacked config.sub a but can't get it to recognise anything, so it won't
configure. I'd appreciate any help on this one.

Adriaan

From bouncefilter Thu Mar 9 00:50:32 2000
Received: from thelab.hub.org (nat195.52.mpoweredpc.net [142.177.195.52])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA92288
for <pgsql-hackers@postgresql.org>; Thu, 9 Mar 2000 00:50:11 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.3) with ESMTP id BAA42403
for <pgsql-hackers@postgresql.org>; Thu, 9 Mar 2000 01:50:11 -0400 (AST)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 9 Mar 2000 01:50:11 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: test ...
Message-ID: <Pine.BSF.4.21.0003090149300.591-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

ignore, we had some problems today with the mailing lists as a result of a
removing some old software, and believe its all in order again *sigh*

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Thu Mar 9 01:04:32 2000
Received: from thelab.hub.org (nat195.52.mpoweredpc.net [142.177.195.52])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA95231
for <pgsql-hackers@postgresql.org>; Thu, 9 Mar 2000 01:03:39 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.3) with ESMTP id CAA42633
for <pgsql-hackers@postgresql.org>; Thu, 9 Mar 2000 02:03:38 -0400 (AST)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 9 Mar 2000 02:03:37 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: ignore
Message-ID: <Pine.BSF.4.21.0003090203300.591-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Thu Mar 9 01:12:32 2000
Received: from thelab.hub.org (nat195.52.mpoweredpc.net [142.177.195.52])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA97453
for <pgsql-hackers@postgresql.org>; Thu, 9 Mar 2000 01:11:33 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.3) with ESMTP id CAA42725
for <pgsql-hackers@postgresql.org>; Thu, 9 Mar 2000 02:11:33 -0400 (AST)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 9 Mar 2000 02:11:33 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: Ack ...
Message-ID: <Pine.BSF.4.21.0003090211240.591-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Thu Mar 9 01:18:32 2000
Received: from thelab.hub.org (nat195.52.mpoweredpc.net [142.177.195.52])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA99229
for <pgsql-hackers@postgresql.org>; Thu, 9 Mar 2000 01:17:42 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.3) with ESMTP id CAA42766
for <pgsql-hackers@postgresql.org>; Thu, 9 Mar 2000 02:17:42 -0400 (AST)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 9 Mar 2000 02:17:41 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: work ...
Message-ID: <Pine.BSF.4.21.0003090217310.591-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Thu Mar 9 01:21:32 2000
Received: from thelab.hub.org (nat195.52.mpoweredpc.net [142.177.195.52])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA99976
for <pgsql-hackers@postgresql.org>; Thu, 9 Mar 2000 01:21:08 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.3) with ESMTP id CAA42779
for <pgsql-hackers@postgresql.org>; Thu, 9 Mar 2000 02:21:04 -0400 (AST)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 9 Mar 2000 02:21:04 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: something just isn't right ...
Message-ID: <Pine.BSF.4.21.0003090220570.591-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Thu Mar 9 01:26:32 2000
Received: from thelab.hub.org (nat195.52.mpoweredpc.net [142.177.195.52])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA01124
for <pgsql-hackers@postgresql.org>; Thu, 9 Mar 2000 01:25:51 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.3) with ESMTP id CAA42816
for <pgsql-hackers@postgresql.org>; Thu, 9 Mar 2000 02:25:50 -0400 (AST)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 9 Mar 2000 02:25:50 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: arg ..
Message-ID: <Pine.BSF.4.21.0003090225410.591-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

try this ..

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

Are we addressing this?

Hi,

first I'm sorry to not fill the form, I'm too lazy, and it's not platform
nor version dependent AFAIK.

I recently posted a question (on Feb 23rd) to pgsql-sql concerning the
fact that update and insert are considered the same thing when you modify
permissions with grant and revoke. (Maybe it was the wrong place to post
it.)

for example a "grant delete" also grants "update" which is completely
wrong. More importantly the user is not informed, and this could lead to
VERY IMPORTANT SECURITY PROBLEMS, like someone who should only be able to
update existing records, have the permission to delete all records...

I've read postgresql documentation, especially the grant and revoke
manpages, and I've found no mention of this bug, which is IMHO a Big
Mistake (tm).

attached to this message you'll find a patch for version 6.5.2 wich
differentiate delete and update, because before they were considered as
"write". The patch only modifies .c .y and .h files, but no documentation.

the new acl rights look like: arRdu
a for append
r for read
R for rules
d for delete
u for update

instead of: arwR
a for append
r for read
w for update AND delete
R for rules

This patch seems to work at least with what I've tested, you'll find a
test session at the end of this message.

I hope this patch will help and that it will be easy to incorporate it in
7.0, which I haven't the time to do for now.

And for the bug report I posted on Feb 23rd on "drop user" which keeps the
user's acl in the database, and the deleted user id being reused, I've not
done anything, but I consider this a major problem. Please consider it for
a next version.

Because I'm not an expert, I suggest you remove gram.c before applying the
patch, in order for this file to be generated again from gram.y, but maybe
this is not necessary.

I'd be very pleased if some people could test this more than I can,
because I don't use postgresql intensively with special permissions.

I'm not sure for some parts of the patch, especially in execMain.c
so if a postgresql hacker could examine it, this would be fine.

dump of test session:
---------------------

------- CUT -------

template1=> create database db;
CREATEDB
template1=> create user john;
CREATE USER
template1=> \connect db
connecting to new database: db
db=> create table t (id INT4, name TEXT);
CREATE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | |
+----------+--------------------------+
db=> grant all on t to john;
CHANGE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=arduR"} |
+----------+--------------------------+
db=> \connect db john
connecting to new database: db as user: john
db=> insert into t (id, name) values (1, 'xxx');
INSERT 18560 1
db=> update t set name = 'yyy' where id=1;
UPDATE 1
db=> select * from t;
id|name
--+----
1|yyy
(1 row)

db=> delete from t;
DELETE 1
db=> select * from t;
id|name
--+----
(0 rows)

db=> insert into t (id, name) values (1, 'xxx');
INSERT 18561 1
db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke update on t from john;
CHANGE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=ardR"} |
+----------+--------------------------+
db=> \connect db john;
connecting to new database: db as user: john
db=> insert into t (id, name) values (2, 'yyy');
INSERT 18592 1
db=> update t set name='modified by john' where id=2;
ERROR: t: Permission denied.
db=> delete from t where id=2;
DELETE 1
db=> select * from t;
id|name
--+----
1|xxx
(1 row)

db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke insert on t from john;
CHANGE
db=> \connect db john;
connecting to new database: db as user: john
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=rdR"} |
+----------+--------------------------+
db=> insert into t (id, name) values (3, 'I try to insert something');
ERROR: t: Permission denied.
db=> delete from t;
DELETE 1
db=> select * from t;
id|name
--+----
(0 rows)

db=> \connect db postgres
connecting to new database: db as user: postgres
db=> insert into t (id, name) values (1, 'xxx');
INSERT 18624 1
db=> \connect db john;
connecting to new database: db as user: john
db=> update t set name='john' where id =1;
ERROR: t: Permission denied.
db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke delete on t from john;
CHANGE
db=> grant update on t to john;
CHANGE
db=> \connect db john;
connecting to new database: db as user: john
db=> delete from t;
ERROR: t: Permission denied.
db=> update t set name='john' where id=1;
UPDATE 1
db=> select * from t;
id|name
--+----
1|john
(1 row)

------- CUT -------

Thank you for reading.

bye,

Jerome ALET - alet@unice.fr - http://cortex.unice.fr/~jerome
Faculte de Medecine de Nice - http://noe.unice.fr - Tel: 04 93 37 76 30
28 Avenue de Valombrose - 06107 NICE Cedex 2 - FRANCE

Content-Description: the 6.5.2 patch

diff -urbw postgresql-6.5.2/src/backend/catalog/aclchk.c postgresql-6.5.2-patched/src/backend/catalog/aclchk.c
--- postgresql-6.5.2/src/backend/catalog/aclchk.c	Mon Aug  2 07:56:53 1999
+++ postgresql-6.5.2-patched/src/backend/catalog/aclchk.c	Wed Mar  1 16:39:44 2000
@@ -381,7 +381,7 @@
* pg_database table, there is still additional permissions
* checking in dbcommands.c
*/
-		if ((mode & ACL_WR) || (mode & ACL_AP))
+		if (mode & ACL_AP)
return ACLCHECK_OK;
}

@@ -390,7 +390,7 @@
* pg_shadow.usecatupd is set.	(This is to let superusers protect
* themselves from themselves.)
*/
-	if (((mode & ACL_WR) || (mode & ACL_AP)) &&
+	if ((mode & ACL_AP) &&
!allowSystemTableMods && IsSystemRelationName(relname) &&
!((Form_pg_shadow) GETSTRUCT(tuple))->usecatupd)
{
diff -urbw postgresql-6.5.2/src/backend/commands/command.c postgresql-6.5.2-patched/src/backend/commands/command.c
--- postgresql-6.5.2/src/backend/commands/command.c	Mon Aug  2 07:56:57 1999
+++ postgresql-6.5.2-patched/src/backend/commands/command.c	Wed Mar  1 16:30:23 2000
@@ -524,7 +524,9 @@
if (lockstmt->mode == AccessShareLock)
aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), ACL_RD);
else
-		aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), ACL_WR);
+		/* do we really need to have all these permissions at the same time ? */
+		/* shouldn't we test lockstmt->mode first ? */
+		aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), (ACL_AP | ACL_DE | ACL_UP));

if (aclresult != ACLCHECK_OK)
elog(ERROR, "LOCK TABLE: permission denied");
diff -urbw postgresql-6.5.2/src/backend/commands/copy.c postgresql-6.5.2-patched/src/backend/commands/copy.c
--- postgresql-6.5.2/src/backend/commands/copy.c	Sat Jul  3 02:32:39 1999
+++ postgresql-6.5.2-patched/src/backend/commands/copy.c	Wed Mar  1 16:30:35 2000
@@ -242,7 +242,8 @@
FILE	   *fp;
Relation	rel;
extern char *UserName;		/* defined in global.c */
-	const AclMode required_access = from ? ACL_WR : ACL_RD;
+	/* why should we need other permissions than APPEND ? */
+	const AclMode required_access = from ? ACL_AP : ACL_RD;
int			result;

rel = heap_openr(relname);
diff -urbw postgresql-6.5.2/src/backend/commands/sequence.c postgresql-6.5.2-patched/src/backend/commands/sequence.c
--- postgresql-6.5.2/src/backend/commands/sequence.c	Mon Aug  2 07:56:59 1999
+++ postgresql-6.5.2-patched/src/backend/commands/sequence.c	Wed Mar  1 16:31:05 2000
@@ -314,7 +314,8 @@
Form_pg_sequence seq;

#ifndef NO_SECURITY
-	if (pg_aclcheck(seqname, getpgusername(), ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than UPDATE permission ? */
+	if (pg_aclcheck(seqname, getpgusername(), ACL_UP) != ACLCHECK_OK)
elog(ERROR, "%s.setval: you don't have permissions to set sequence %s",
seqname, seqname);
#endif
diff -urbw postgresql-6.5.2/src/backend/commands/user.c postgresql-6.5.2-patched/src/backend/commands/user.c
--- postgresql-6.5.2/src/backend/commands/user.c	Mon Aug  2 07:56:59 1999
+++ postgresql-6.5.2-patched/src/backend/commands/user.c	Wed Mar  1 16:31:38 2000
@@ -115,7 +115,7 @@
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR | ACL_AP) != ACLCHECK_OK)
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_AP | ACL_DE | ACL_UP) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "defineUser: user \"%s\" does not have SELECT and INSERT privilege for \"%s\"",
@@ -227,7 +227,8 @@
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than UPDATE ? */
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_UP) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "alterUser: user \"%s\" does not have SELECT and UPDATE privilege for \"%s\"",
@@ -329,11 +330,12 @@
BeginTransactionBlock();

/*
-	 * Make sure the user attempting to create a user can delete from the
+	 * Make sure the user attempting to delete a user can delete from the
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than DELETE ? */
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_DE) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "removeUser: user \"%s\" does not have SELECT and DELETE privilege for \"%s\"",
diff -urbw postgresql-6.5.2/src/backend/executor/execMain.c postgresql-6.5.2-patched/src/backend/executor/execMain.c
--- postgresql-6.5.2/src/backend/executor/execMain.c	Thu Jun 17 17:15:49 1999
+++ postgresql-6.5.2-patched/src/backend/executor/execMain.c	Wed Mar  1 18:31:31 2000
@@ -464,14 +464,16 @@
switch (operation)
{
case CMD_INSERT:
-					ok = ((aclcheck_result = CHECK(ACL_AP)) == ACLCHECK_OK) ||
-						((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
+					ok = ((aclcheck_result = CHECK(ACL_AP)) == ACLCHECK_OK);
opstr = "append";
break;
case CMD_DELETE:
+					ok = ((aclcheck_result = CHECK(ACL_DE)) == ACLCHECK_OK);
+					opstr = "delete";
+					break;
case CMD_UPDATE:
-					ok = ((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
-					opstr = "write";
+					ok = ((aclcheck_result = CHECK(ACL_UP)) == ACLCHECK_OK);
+					opstr = "update";
break;
default:
elog(ERROR, "ExecCheckPerms: bogus operation %d",
@@ -508,8 +510,9 @@
StrNCpy(rname.data,
((Form_pg_class) GETSTRUCT(htup))->relname.data,
NAMEDATALEN);
-			ok = ((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
-			opstr = "write";
+			/* is it the right thing to do ? */
+			ok = ((aclcheck_result = CHECK((ACL_AP | ACL_DE | ACL_UP))) == ACLCHECK_OK);
+			opstr = "write";	/* unused ? */
if (!ok)
elog(ERROR, "%s: %s", rname.data, aclcheck_error_strings[aclcheck_result]);
}
diff -urbw postgresql-6.5.2/src/backend/parser/gram.y postgresql-6.5.2-patched/src/backend/parser/gram.y
--- postgresql-6.5.2/src/backend/parser/gram.y	Tue Sep 14 08:07:35 1999
+++ postgresql-6.5.2-patched/src/backend/parser/gram.y	Wed Mar  1 16:33:34 2000
@@ -1694,11 +1694,11 @@

privileges:  ALL PRIVILEGES
{
-				 $$ = aclmakepriv("rwaR",0);
+				 $$ = aclmakepriv("raduR",0);
}
| ALL
{
-				 $$ = aclmakepriv("rwaR",0);
+				 $$ = aclmakepriv("raduR",0);
}
| operation_commalist
{
@@ -1726,11 +1726,11 @@
}
| UPDATE
{
-						$$ = ACL_MODE_WR_CHR;
+						$$ = ACL_MODE_UP_CHR;
}
| DELETE
{
-						$$ = ACL_MODE_WR_CHR;
+						$$ = ACL_MODE_DE_CHR;
}
| RULE
{
diff -urbw postgresql-6.5.2/src/backend/parser/parse.h postgresql-6.5.2-patched/src/backend/parser/parse.h
--- postgresql-6.5.2/src/backend/parser/parse.h	Thu Sep 16 02:23:39 1999
+++ postgresql-6.5.2-patched/src/backend/parser/parse.h	Wed Mar  1 18:34:46 2000
@@ -29,236 +29,236 @@
RuleStmt			*rstmt;
InsertStmt			*astmt;
} YYSTYPE;
-#define	ABSOLUTE	257
-#define	ACTION	258
-#define	ADD	259
-#define	ALL	260
-#define	ALTER	261
-#define	AND	262
-#define	ANY	263
-#define	AS	264
-#define	ASC	265
-#define	BEGIN_TRANS	266
-#define	BETWEEN	267
-#define	BOTH	268
-#define	BY	269
-#define	CASCADE	270
-#define	CASE	271
-#define	CAST	272
-#define	CHAR	273
-#define	CHARACTER	274
-#define	CHECK	275
-#define	CLOSE	276
-#define	COALESCE	277
-#define	COLLATE	278
-#define	COLUMN	279
-#define	COMMIT	280
-#define	CONSTRAINT	281
-#define	CREATE	282
-#define	CROSS	283
-#define	CURRENT	284
-#define	CURRENT_DATE	285
-#define	CURRENT_TIME	286
-#define	CURRENT_TIMESTAMP	287
-#define	CURRENT_USER	288
-#define	CURSOR	289
-#define	DAY_P	290
-#define	DECIMAL	291
-#define	DECLARE	292
-#define	DEFAULT	293
-#define	DELETE	294
-#define	DESC	295
-#define	DISTINCT	296
-#define	DOUBLE	297
-#define	DROP	298
-#define	ELSE	299
-#define	END_TRANS	300
-#define	EXCEPT	301
-#define	EXECUTE	302
-#define	EXISTS	303
-#define	EXTRACT	304
-#define	FALSE_P	305
-#define	FETCH	306
-#define	FLOAT	307
-#define	FOR	308
-#define	FOREIGN	309
-#define	FROM	310
-#define	FULL	311
-#define	GLOBAL	312
-#define	GRANT	313
-#define	GROUP	314
-#define	HAVING	315
-#define	HOUR_P	316
-#define	IN	317
-#define	INNER_P	318
-#define	INSENSITIVE	319
-#define	INSERT	320
-#define	INTERSECT	321
-#define	INTERVAL	322
-#define	INTO	323
-#define	IS	324
-#define	ISOLATION	325
-#define	JOIN	326
-#define	KEY	327
-#define	LANGUAGE	328
-#define	LEADING	329
-#define	LEFT	330
-#define	LEVEL	331
-#define	LIKE	332
-#define	LOCAL	333
-#define	MATCH	334
-#define	MINUTE_P	335
-#define	MONTH_P	336
-#define	NAMES	337
-#define	NATIONAL	338
-#define	NATURAL	339
-#define	NCHAR	340
-#define	NEXT	341
-#define	NO	342
-#define	NOT	343
-#define	NULLIF	344
-#define	NULL_P	345
-#define	NUMERIC	346
-#define	OF	347
-#define	ON	348
-#define	ONLY	349
-#define	OPTION	350
-#define	OR	351
-#define	ORDER	352
-#define	OUTER_P	353
-#define	PARTIAL	354
-#define	POSITION	355
-#define	PRECISION	356
-#define	PRIMARY	357
-#define	PRIOR	358
-#define	PRIVILEGES	359
-#define	PROCEDURE	360
-#define	PUBLIC	361
-#define	READ	362
-#define	REFERENCES	363
-#define	RELATIVE	364
-#define	REVOKE	365
-#define	RIGHT	366
-#define	ROLLBACK	367
-#define	SCROLL	368
-#define	SECOND_P	369
-#define	SELECT	370
-#define	SET	371
-#define	SUBSTRING	372
-#define	TABLE	373
-#define	TEMP	374
-#define	TEMPORARY	375
-#define	THEN	376
-#define	TIME	377
-#define	TIMESTAMP	378
-#define	TIMEZONE_HOUR	379
-#define	TIMEZONE_MINUTE	380
-#define	TO	381
-#define	TRAILING	382
-#define	TRANSACTION	383
-#define	TRIM	384
-#define	TRUE_P	385
-#define	UNION	386
-#define	UNIQUE	387
-#define	UPDATE	388
-#define	USER	389
-#define	USING	390
-#define	VALUES	391
-#define	VARCHAR	392
-#define	VARYING	393
-#define	VIEW	394
-#define	WHEN	395
-#define	WHERE	396
-#define	WITH	397
-#define	WORK	398
-#define	YEAR_P	399
-#define	ZONE	400
-#define	TRIGGER	401
-#define	COMMITTED	402
-#define	SERIALIZABLE	403
-#define	TYPE_P	404
-#define	ABORT_TRANS	405
-#define	ACCESS	406
-#define	AFTER	407
-#define	AGGREGATE	408
-#define	ANALYZE	409
-#define	BACKWARD	410
-#define	BEFORE	411
-#define	BINARY	412
-#define	CACHE	413
-#define	CLUSTER	414
-#define	COPY	415
-#define	CREATEDB	416
-#define	CREATEUSER	417
-#define	CYCLE	418
-#define	DATABASE	419
-#define	DELIMITERS	420
-#define	DO	421
-#define	EACH	422
-#define	ENCODING	423
-#define	EXCLUSIVE	424
-#define	EXPLAIN	425
-#define	EXTEND	426
-#define	FORWARD	427
-#define	FUNCTION	428
-#define	HANDLER	429
-#define	INCREMENT	430
-#define	INDEX	431
-#define	INHERITS	432
-#define	INSTEAD	433
-#define	ISNULL	434
-#define	LANCOMPILER	435
-#define	LIMIT	436
-#define	LISTEN	437
-#define	LOAD	438
-#define	LOCATION	439
-#define	LOCK_P	440
-#define	MAXVALUE	441
-#define	MINVALUE	442
-#define	MODE	443
-#define	MOVE	444
-#define	NEW	445
-#define	NOCREATEDB	446
-#define	NOCREATEUSER	447
-#define	NONE	448
-#define	NOTHING	449
-#define	NOTIFY	450
-#define	NOTNULL	451
-#define	OFFSET	452
-#define	OIDS	453
-#define	OPERATOR	454
-#define	PASSWORD	455
-#define	PROCEDURAL	456
-#define	RENAME	457
-#define	RESET	458
-#define	RETURNS	459
-#define	ROW	460
-#define	RULE	461
-#define	SEQUENCE	462
-#define	SERIAL	463
-#define	SETOF	464
-#define	SHARE	465
-#define	SHOW	466
-#define	START	467
-#define	STATEMENT	468
-#define	STDIN	469
-#define	STDOUT	470
-#define	TRUSTED	471
-#define	UNLISTEN	472
-#define	UNTIL	473
-#define	VACUUM	474
-#define	VALID	475
-#define	VERBOSE	476
-#define	VERSION	477
-#define	IDENT	478
-#define	SCONST	479
-#define	Op	480
-#define	ICONST	481
-#define	PARAM	482
-#define	FCONST	483
-#define	OP	484
-#define	UMINUS	485
-#define	TYPECAST	486
+#define	ABSOLUTE	258
+#define	ACTION	259
+#define	ADD	260
+#define	ALL	261
+#define	ALTER	262
+#define	AND	263
+#define	ANY	264
+#define	AS	265
+#define	ASC	266
+#define	BEGIN_TRANS	267
+#define	BETWEEN	268
+#define	BOTH	269
+#define	BY	270
+#define	CASCADE	271
+#define	CASE	272
+#define	CAST	273
+#define	CHAR	274
+#define	CHARACTER	275
+#define	CHECK	276
+#define	CLOSE	277
+#define	COALESCE	278
+#define	COLLATE	279
+#define	COLUMN	280
+#define	COMMIT	281
+#define	CONSTRAINT	282
+#define	CREATE	283
+#define	CROSS	284
+#define	CURRENT	285
+#define	CURRENT_DATE	286
+#define	CURRENT_TIME	287
+#define	CURRENT_TIMESTAMP	288
+#define	CURRENT_USER	289
+#define	CURSOR	290
+#define	DAY_P	291
+#define	DECIMAL	292
+#define	DECLARE	293
+#define	DEFAULT	294
+#define	DELETE	295
+#define	DESC	296
+#define	DISTINCT	297
+#define	DOUBLE	298
+#define	DROP	299
+#define	ELSE	300
+#define	END_TRANS	301
+#define	EXCEPT	302
+#define	EXECUTE	303
+#define	EXISTS	304
+#define	EXTRACT	305
+#define	FALSE_P	306
+#define	FETCH	307
+#define	FLOAT	308
+#define	FOR	309
+#define	FOREIGN	310
+#define	FROM	311
+#define	FULL	312
+#define	GLOBAL	313
+#define	GRANT	314
+#define	GROUP	315
+#define	HAVING	316
+#define	HOUR_P	317
+#define	IN	318
+#define	INNER_P	319
+#define	INSENSITIVE	320
+#define	INSERT	321
+#define	INTERSECT	322
+#define	INTERVAL	323
+#define	INTO	324
+#define	IS	325
+#define	ISOLATION	326
+#define	JOIN	327
+#define	KEY	328
+#define	LANGUAGE	329
+#define	LEADING	330
+#define	LEFT	331
+#define	LEVEL	332
+#define	LIKE	333
+#define	LOCAL	334
+#define	MATCH	335
+#define	MINUTE_P	336
+#define	MONTH_P	337
+#define	NAMES	338
+#define	NATIONAL	339
+#define	NATURAL	340
+#define	NCHAR	341
+#define	NEXT	342
+#define	NO	343
+#define	NOT	344
+#define	NULLIF	345
+#define	NULL_P	346
+#define	NUMERIC	347
+#define	OF	348
+#define	ON	349
+#define	ONLY	350
+#define	OPTION	351
+#define	OR	352
+#define	ORDER	353
+#define	OUTER_P	354
+#define	PARTIAL	355
+#define	POSITION	356
+#define	PRECISION	357
+#define	PRIMARY	358
+#define	PRIOR	359
+#define	PRIVILEGES	360
+#define	PROCEDURE	361
+#define	PUBLIC	362
+#define	READ	363
+#define	REFERENCES	364
+#define	RELATIVE	365
+#define	REVOKE	366
+#define	RIGHT	367
+#define	ROLLBACK	368
+#define	SCROLL	369
+#define	SECOND_P	370
+#define	SELECT	371
+#define	SET	372
+#define	SUBSTRING	373
+#define	TABLE	374
+#define	TEMP	375
+#define	TEMPORARY	376
+#define	THEN	377
+#define	TIME	378
+#define	TIMESTAMP	379
+#define	TIMEZONE_HOUR	380
+#define	TIMEZONE_MINUTE	381
+#define	TO	382
+#define	TRAILING	383
+#define	TRANSACTION	384
+#define	TRIM	385
+#define	TRUE_P	386
+#define	UNION	387
+#define	UNIQUE	388
+#define	UPDATE	389
+#define	USER	390
+#define	USING	391
+#define	VALUES	392
+#define	VARCHAR	393
+#define	VARYING	394
+#define	VIEW	395
+#define	WHEN	396
+#define	WHERE	397
+#define	WITH	398
+#define	WORK	399
+#define	YEAR_P	400
+#define	ZONE	401
+#define	TRIGGER	402
+#define	COMMITTED	403
+#define	SERIALIZABLE	404
+#define	TYPE_P	405
+#define	ABORT_TRANS	406
+#define	ACCESS	407
+#define	AFTER	408
+#define	AGGREGATE	409
+#define	ANALYZE	410
+#define	BACKWARD	411
+#define	BEFORE	412
+#define	BINARY	413
+#define	CACHE	414
+#define	CLUSTER	415
+#define	COPY	416
+#define	CREATEDB	417
+#define	CREATEUSER	418
+#define	CYCLE	419
+#define	DATABASE	420
+#define	DELIMITERS	421
+#define	DO	422
+#define	EACH	423
+#define	ENCODING	424
+#define	EXCLUSIVE	425
+#define	EXPLAIN	426
+#define	EXTEND	427
+#define	FORWARD	428
+#define	FUNCTION	429
+#define	HANDLER	430
+#define	INCREMENT	431
+#define	INDEX	432
+#define	INHERITS	433
+#define	INSTEAD	434
+#define	ISNULL	435
+#define	LANCOMPILER	436
+#define	LIMIT	437
+#define	LISTEN	438
+#define	LOAD	439
+#define	LOCATION	440
+#define	LOCK_P	441
+#define	MAXVALUE	442
+#define	MINVALUE	443
+#define	MODE	444
+#define	MOVE	445
+#define	NEW	446
+#define	NOCREATEDB	447
+#define	NOCREATEUSER	448
+#define	NONE	449
+#define	NOTHING	450
+#define	NOTIFY	451
+#define	NOTNULL	452
+#define	OFFSET	453
+#define	OIDS	454
+#define	OPERATOR	455
+#define	PASSWORD	456
+#define	PROCEDURAL	457
+#define	RENAME	458
+#define	RESET	459
+#define	RETURNS	460
+#define	ROW	461
+#define	RULE	462
+#define	SEQUENCE	463
+#define	SERIAL	464
+#define	SETOF	465
+#define	SHARE	466
+#define	SHOW	467
+#define	START	468
+#define	STATEMENT	469
+#define	STDIN	470
+#define	STDOUT	471
+#define	TRUSTED	472
+#define	UNLISTEN	473
+#define	UNTIL	474
+#define	VACUUM	475
+#define	VALID	476
+#define	VERBOSE	477
+#define	VERSION	478
+#define	IDENT	479
+#define	SCONST	480
+#define	Op	481
+#define	ICONST	482
+#define	PARAM	483
+#define	FCONST	484
+#define	OP	485
+#define	UMINUS	486
+#define	TYPECAST	487

extern YYSTYPE yylval;
diff -urbw postgresql-6.5.2/src/backend/parser/parse_func.c postgresql-6.5.2-patched/src/backend/parser/parse_func.c
--- postgresql-6.5.2/src/backend/parser/parse_func.c	Fri Jun 18 00:21:40 1999
+++ postgresql-6.5.2-patched/src/backend/parser/parse_func.c	Wed Mar  1 16:33:53 2000
@@ -601,7 +601,8 @@

if ((aclcheck_result = pg_aclcheck(seqrel, GetPgUserName(),
(((funcid == F_NEXTVAL) || (funcid == F_SETVAL)) ?
-						ACL_WR : ACL_RD)))
+						/* if nextval and setval are atomic, which I don't know, update should be enough */
+						ACL_UP : ACL_RD)))
!= ACLCHECK_OK)
elog(ERROR, "%s.%s: %s",
seqrel, funcname, aclcheck_error_strings[aclcheck_result]);
diff -urbw postgresql-6.5.2/src/backend/rewrite/locks.c postgresql-6.5.2-patched/src/backend/rewrite/locks.c
--- postgresql-6.5.2/src/backend/rewrite/locks.c	Sun Feb 14 00:17:44 1999
+++ postgresql-6.5.2-patched/src/backend/rewrite/locks.c	Wed Mar  1 16:34:20 2000
@@ -228,8 +228,15 @@
case CMD_INSERT:
reqperm = ACL_AP;
break;
+						case CMD_DELETE:
+							reqperm = ACL_DE;
+							break;
+						case CMD_UPDATE:
+							reqperm = ACL_UP;
+							break;
default:
-							reqperm = ACL_WR;
+							/* is it The Right Thing To Do (tm) ? */
+							reqperm = ACL_AP | ACL_DE | ACL_UP;
break;
}
else
diff -urbw postgresql-6.5.2/src/backend/rewrite/rewriteHandler.c postgresql-6.5.2-patched/src/backend/rewrite/rewriteHandler.c
--- postgresql-6.5.2/src/backend/rewrite/rewriteHandler.c	Sun Jul 11 19:54:30 1999
+++ postgresql-6.5.2-patched/src/backend/rewrite/rewriteHandler.c	Wed Mar  1 16:35:01 2000
@@ -2282,8 +2282,15 @@
case CMD_INSERT:
reqperm = ACL_AP;
break;
+				case CMD_DELETE:
+					reqperm = ACL_DE;
+					break;
+				case CMD_UPDATE:
+					reqperm = ACL_UP;
+					break;
default:
-					reqperm = ACL_WR;
+					/* is it The Right Thing To Do (tm) ? */
+					reqperm = ACL_AP | ACL_DE | ACL_UP;
break;
}

diff -urbw postgresql-6.5.2/src/backend/storage/file/fd.c postgresql-6.5.2-patched/src/backend/storage/file/fd.c
diff -urbw postgresql-6.5.2/src/backend/utils/adt/acl.c postgresql-6.5.2-patched/src/backend/utils/adt/acl.c
--- postgresql-6.5.2/src/backend/utils/adt/acl.c	Mon Aug  2 07:24:49 1999
+++ postgresql-6.5.2-patched/src/backend/utils/adt/acl.c	Wed Mar  1 16:35:53 2000
@@ -154,8 +154,11 @@
case ACL_MODE_RD_CHR:
aip->ai_mode |= ACL_RD;
break;
-			case ACL_MODE_WR_CHR:
-				aip->ai_mode |= ACL_WR;
+			case ACL_MODE_DE_CHR:
+				aip->ai_mode |= ACL_DE;
+				break;
+			case ACL_MODE_UP_CHR:
+				aip->ai_mode |= ACL_UP;
break;
case ACL_MODE_RU_CHR:
aip->ai_mode |= ACL_RU;
@@ -272,7 +275,7 @@
if (!aip)
aip = &default_aclitem;

-	p = out = palloc(strlen("group =arwR ") + 1 + NAMEDATALEN);
+	p = out = palloc(strlen("group =arRdu ") + 1 + NAMEDATALEN);
if (!out)
elog(ERROR, "aclitemout: palloc failed");
*p = '\0';
@@ -605,9 +608,8 @@
int			i;
int			l;

-	Assert(strlen(old_privlist) < 5);
-	priv = palloc(5); /* at most "rwaR" */ ;
-
+	Assert(strlen(old_privlist) < 6);
+	priv = palloc(6); /* at most "arduR" */ ;
if (old_privlist == NULL || old_privlist[0] == '\0')
{
priv[0] = new_priv;
@@ -619,7 +621,7 @@

l = strlen(old_privlist);

-	if (l == 4)
+	if (l == 5)
{							/* can't add any more privileges */
return priv;
}
diff -urbw postgresql-6.5.2/src/include/utils/acl.h postgresql-6.5.2-patched/src/include/utils/acl.h
--- postgresql-6.5.2/src/include/utils/acl.h	Fri Jul 30 19:07:22 1999
+++ postgresql-6.5.2-patched/src/include/utils/acl.h	Wed Mar  1 16:40:50 2000
@@ -54,9 +54,10 @@
#define ACL_NO			0		/* no permissions */
#define ACL_AP			(1<<0)	/* append */
#define ACL_RD			(1<<1)	/* read */
-#define ACL_WR			(1<<2)	/* write (append/delete/replace) */
-#define ACL_RU			(1<<3)	/* place rules */
-#define N_ACL_MODES		4
+#define ACL_DE			(1<<2)	/* delete */
+#define ACL_UP			(1<<3)	/* update/replace */
+#define ACL_RU			(1<<4)	/* place rules */
+#define N_ACL_MODES		5

#define ACL_MODECHG_ADD			1
#define ACL_MODECHG_DEL			2
@@ -65,7 +66,8 @@
/* change this line if you want to set the default acl permission  */
#define ACL_WORLD_DEFAULT		(ACL_NO)
/* #define		ACL_WORLD_DEFAULT		(ACL_RD|ACL_WR|ACL_AP|ACL_RU) */
-#define ACL_OWNER_DEFAULT		(ACL_RD|ACL_WR|ACL_AP|ACL_RU)
+
+#define ACL_OWNER_DEFAULT		(ACL_AP|ACL_RD|ACL_RU|ACL_DE|ACL_UP)

/*
* AclItem
@@ -118,10 +120,12 @@
#define ACL_MODECHG_ADD_CHR		'+'
#define ACL_MODECHG_DEL_CHR		'-'
#define ACL_MODECHG_EQL_CHR		'='
-#define ACL_MODE_STR			"arwR"	/* list of valid characters */
+
+#define ACL_MODE_STR			"arduR"	 /* list of valid characters */
#define ACL_MODE_AP_CHR			'a'
#define ACL_MODE_RD_CHR			'r'
-#define ACL_MODE_WR_CHR			'w'
+#define ACL_MODE_DE_CHR			'd'
+#define ACL_MODE_UP_CHR			'u'
#define ACL_MODE_RU_CHR			'R'

/* result codes for pg_aclcheck */

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Fri, 9 Jun 2000, Bruce Momjian wrote:

Are we addressing this?

Yes, please do.

And please don't forget the following:

when dropping an user postgresql (actually the superuser must do it
manually) should first revoke all user's permissions on all databases,
because the deleted userid is reused on the next create user so the new
user inherits all permissions from the deleted user => may be very very
bad (an example of what can be done is not necessary I suppose ?)

And for the bug report I posted on Feb 23rd on "drop user" which keeps the
user's acl in the database, and the deleted user id being reused, I've not
done anything, but I consider this a major problem. Please consider it for
a next version.

bye,
Jerome ALET - alet@unice.fr - http://cortex.unice.fr/~jerome
Faculte de Medecine de Nice - http://noe.unice.fr - Tel: 04 93 37 76 30
28 Avenue de Valombrose - 06107 NICE Cedex 2 - FRANCE

OK, this was a good point. Were did we leave this, folks?

Hi,

first I'm sorry to not fill the form, I'm too lazy, and it's not platform
nor version dependent AFAIK.

I recently posted a question (on Feb 23rd) to pgsql-sql concerning the
fact that update and insert are considered the same thing when you modify
permissions with grant and revoke. (Maybe it was the wrong place to post
it.)

for example a "grant delete" also grants "update" which is completely
wrong. More importantly the user is not informed, and this could lead to
VERY IMPORTANT SECURITY PROBLEMS, like someone who should only be able to
update existing records, have the permission to delete all records...

I've read postgresql documentation, especially the grant and revoke
manpages, and I've found no mention of this bug, which is IMHO a Big
Mistake (tm).

attached to this message you'll find a patch for version 6.5.2 wich
differentiate delete and update, because before they were considered as
"write". The patch only modifies .c .y and .h files, but no documentation.

the new acl rights look like: arRdu
a for append
r for read
R for rules
d for delete
u for update

instead of: arwR
a for append
r for read
w for update AND delete
R for rules

This patch seems to work at least with what I've tested, you'll find a
test session at the end of this message.

I hope this patch will help and that it will be easy to incorporate it in
7.0, which I haven't the time to do for now.

And for the bug report I posted on Feb 23rd on "drop user" which keeps the
user's acl in the database, and the deleted user id being reused, I've not
done anything, but I consider this a major problem. Please consider it for
a next version.

Because I'm not an expert, I suggest you remove gram.c before applying the
patch, in order for this file to be generated again from gram.y, but maybe
this is not necessary.

I'd be very pleased if some people could test this more than I can,
because I don't use postgresql intensively with special permissions.

I'm not sure for some parts of the patch, especially in execMain.c
so if a postgresql hacker could examine it, this would be fine.

dump of test session:
---------------------

------- CUT -------

template1=> create database db;
CREATEDB
template1=> create user john;
CREATE USER
template1=> \connect db
connecting to new database: db
db=> create table t (id INT4, name TEXT);
CREATE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | |
+----------+--------------------------+
db=> grant all on t to john;
CHANGE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=arduR"} |
+----------+--------------------------+
db=> \connect db john
connecting to new database: db as user: john
db=> insert into t (id, name) values (1, 'xxx');
INSERT 18560 1
db=> update t set name = 'yyy' where id=1;
UPDATE 1
db=> select * from t;
id|name
--+----
1|yyy
(1 row)

db=> delete from t;
DELETE 1
db=> select * from t;
id|name
--+----
(0 rows)

db=> insert into t (id, name) values (1, 'xxx');
INSERT 18561 1
db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke update on t from john;
CHANGE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=ardR"} |
+----------+--------------------------+
db=> \connect db john;
connecting to new database: db as user: john
db=> insert into t (id, name) values (2, 'yyy');
INSERT 18592 1
db=> update t set name='modified by john' where id=2;
ERROR: t: Permission denied.
db=> delete from t where id=2;
DELETE 1
db=> select * from t;
id|name
--+----
1|xxx
(1 row)

db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke insert on t from john;
CHANGE
db=> \connect db john;
connecting to new database: db as user: john
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=rdR"} |
+----------+--------------------------+
db=> insert into t (id, name) values (3, 'I try to insert something');
ERROR: t: Permission denied.
db=> delete from t;
DELETE 1
db=> select * from t;
id|name
--+----
(0 rows)

db=> \connect db postgres
connecting to new database: db as user: postgres
db=> insert into t (id, name) values (1, 'xxx');
INSERT 18624 1
db=> \connect db john;
connecting to new database: db as user: john
db=> update t set name='john' where id =1;
ERROR: t: Permission denied.
db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke delete on t from john;
CHANGE
db=> grant update on t to john;
CHANGE
db=> \connect db john;
connecting to new database: db as user: john
db=> delete from t;
ERROR: t: Permission denied.
db=> update t set name='john' where id=1;
UPDATE 1
db=> select * from t;
id|name
--+----
1|john
(1 row)

------- CUT -------

Thank you for reading.

bye,

Jerome ALET - alet@unice.fr - http://cortex.unice.fr/~jerome
Faculte de Medecine de Nice - http://noe.unice.fr - Tel: 04 93 37 76 30
28 Avenue de Valombrose - 06107 NICE Cedex 2 - FRANCE

Content-Description: the 6.5.2 patch

diff -urbw postgresql-6.5.2/src/backend/catalog/aclchk.c postgresql-6.5.2-patched/src/backend/catalog/aclchk.c
--- postgresql-6.5.2/src/backend/catalog/aclchk.c	Mon Aug  2 07:56:53 1999
+++ postgresql-6.5.2-patched/src/backend/catalog/aclchk.c	Wed Mar  1 16:39:44 2000
@@ -381,7 +381,7 @@
* pg_database table, there is still additional permissions
* checking in dbcommands.c
*/
-		if ((mode & ACL_WR) || (mode & ACL_AP))
+		if (mode & ACL_AP)
return ACLCHECK_OK;
}

@@ -390,7 +390,7 @@
* pg_shadow.usecatupd is set.	(This is to let superusers protect
* themselves from themselves.)
*/
-	if (((mode & ACL_WR) || (mode & ACL_AP)) &&
+	if ((mode & ACL_AP) &&
!allowSystemTableMods && IsSystemRelationName(relname) &&
!((Form_pg_shadow) GETSTRUCT(tuple))->usecatupd)
{
diff -urbw postgresql-6.5.2/src/backend/commands/command.c postgresql-6.5.2-patched/src/backend/commands/command.c
--- postgresql-6.5.2/src/backend/commands/command.c	Mon Aug  2 07:56:57 1999
+++ postgresql-6.5.2-patched/src/backend/commands/command.c	Wed Mar  1 16:30:23 2000
@@ -524,7 +524,9 @@
if (lockstmt->mode == AccessShareLock)
aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), ACL_RD);
else
-		aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), ACL_WR);
+		/* do we really need to have all these permissions at the same time ? */
+		/* shouldn't we test lockstmt->mode first ? */
+		aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), (ACL_AP | ACL_DE | ACL_UP));

if (aclresult != ACLCHECK_OK)
elog(ERROR, "LOCK TABLE: permission denied");
diff -urbw postgresql-6.5.2/src/backend/commands/copy.c postgresql-6.5.2-patched/src/backend/commands/copy.c
--- postgresql-6.5.2/src/backend/commands/copy.c	Sat Jul  3 02:32:39 1999
+++ postgresql-6.5.2-patched/src/backend/commands/copy.c	Wed Mar  1 16:30:35 2000
@@ -242,7 +242,8 @@
FILE	   *fp;
Relation	rel;
extern char *UserName;		/* defined in global.c */
-	const AclMode required_access = from ? ACL_WR : ACL_RD;
+	/* why should we need other permissions than APPEND ? */
+	const AclMode required_access = from ? ACL_AP : ACL_RD;
int			result;

rel = heap_openr(relname);
diff -urbw postgresql-6.5.2/src/backend/commands/sequence.c postgresql-6.5.2-patched/src/backend/commands/sequence.c
--- postgresql-6.5.2/src/backend/commands/sequence.c	Mon Aug  2 07:56:59 1999
+++ postgresql-6.5.2-patched/src/backend/commands/sequence.c	Wed Mar  1 16:31:05 2000
@@ -314,7 +314,8 @@
Form_pg_sequence seq;

#ifndef NO_SECURITY
-	if (pg_aclcheck(seqname, getpgusername(), ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than UPDATE permission ? */
+	if (pg_aclcheck(seqname, getpgusername(), ACL_UP) != ACLCHECK_OK)
elog(ERROR, "%s.setval: you don't have permissions to set sequence %s",
seqname, seqname);
#endif
diff -urbw postgresql-6.5.2/src/backend/commands/user.c postgresql-6.5.2-patched/src/backend/commands/user.c
--- postgresql-6.5.2/src/backend/commands/user.c	Mon Aug  2 07:56:59 1999
+++ postgresql-6.5.2-patched/src/backend/commands/user.c	Wed Mar  1 16:31:38 2000
@@ -115,7 +115,7 @@
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR | ACL_AP) != ACLCHECK_OK)
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_AP | ACL_DE | ACL_UP) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "defineUser: user \"%s\" does not have SELECT and INSERT privilege for \"%s\"",
@@ -227,7 +227,8 @@
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than UPDATE ? */
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_UP) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "alterUser: user \"%s\" does not have SELECT and UPDATE privilege for \"%s\"",
@@ -329,11 +330,12 @@
BeginTransactionBlock();

/*
-	 * Make sure the user attempting to create a user can delete from the
+	 * Make sure the user attempting to delete a user can delete from the
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than DELETE ? */
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_DE) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "removeUser: user \"%s\" does not have SELECT and DELETE privilege for \"%s\"",
diff -urbw postgresql-6.5.2/src/backend/executor/execMain.c postgresql-6.5.2-patched/src/backend/executor/execMain.c
--- postgresql-6.5.2/src/backend/executor/execMain.c	Thu Jun 17 17:15:49 1999
+++ postgresql-6.5.2-patched/src/backend/executor/execMain.c	Wed Mar  1 18:31:31 2000
@@ -464,14 +464,16 @@
switch (operation)
{
case CMD_INSERT:
-					ok = ((aclcheck_result = CHECK(ACL_AP)) == ACLCHECK_OK) ||
-						((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
+					ok = ((aclcheck_result = CHECK(ACL_AP)) == ACLCHECK_OK);
opstr = "append";
break;
case CMD_DELETE:
+					ok = ((aclcheck_result = CHECK(ACL_DE)) == ACLCHECK_OK);
+					opstr = "delete";
+					break;
case CMD_UPDATE:
-					ok = ((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
-					opstr = "write";
+					ok = ((aclcheck_result = CHECK(ACL_UP)) == ACLCHECK_OK);
+					opstr = "update";
break;
default:
elog(ERROR, "ExecCheckPerms: bogus operation %d",
@@ -508,8 +510,9 @@
StrNCpy(rname.data,
((Form_pg_class) GETSTRUCT(htup))->relname.data,
NAMEDATALEN);
-			ok = ((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
-			opstr = "write";
+			/* is it the right thing to do ? */
+			ok = ((aclcheck_result = CHECK((ACL_AP | ACL_DE | ACL_UP))) == ACLCHECK_OK);
+			opstr = "write";	/* unused ? */
if (!ok)
elog(ERROR, "%s: %s", rname.data, aclcheck_error_strings[aclcheck_result]);
}
diff -urbw postgresql-6.5.2/src/backend/parser/gram.y postgresql-6.5.2-patched/src/backend/parser/gram.y
--- postgresql-6.5.2/src/backend/parser/gram.y	Tue Sep 14 08:07:35 1999
+++ postgresql-6.5.2-patched/src/backend/parser/gram.y	Wed Mar  1 16:33:34 2000
@@ -1694,11 +1694,11 @@

privileges:  ALL PRIVILEGES
{
-				 $$ = aclmakepriv("rwaR",0);
+				 $$ = aclmakepriv("raduR",0);
}
| ALL
{
-				 $$ = aclmakepriv("rwaR",0);
+				 $$ = aclmakepriv("raduR",0);
}
| operation_commalist
{
@@ -1726,11 +1726,11 @@
}
| UPDATE
{
-						$$ = ACL_MODE_WR_CHR;
+						$$ = ACL_MODE_UP_CHR;
}
| DELETE
{
-						$$ = ACL_MODE_WR_CHR;
+						$$ = ACL_MODE_DE_CHR;
}
| RULE
{
diff -urbw postgresql-6.5.2/src/backend/parser/parse.h postgresql-6.5.2-patched/src/backend/parser/parse.h
--- postgresql-6.5.2/src/backend/parser/parse.h	Thu Sep 16 02:23:39 1999
+++ postgresql-6.5.2-patched/src/backend/parser/parse.h	Wed Mar  1 18:34:46 2000
@@ -29,236 +29,236 @@
RuleStmt			*rstmt;
InsertStmt			*astmt;
} YYSTYPE;
-#define	ABSOLUTE	257
-#define	ACTION	258
-#define	ADD	259
-#define	ALL	260
-#define	ALTER	261
-#define	AND	262
-#define	ANY	263
-#define	AS	264
-#define	ASC	265
-#define	BEGIN_TRANS	266
-#define	BETWEEN	267
-#define	BOTH	268
-#define	BY	269
-#define	CASCADE	270
-#define	CASE	271
-#define	CAST	272
-#define	CHAR	273
-#define	CHARACTER	274
-#define	CHECK	275
-#define	CLOSE	276
-#define	COALESCE	277
-#define	COLLATE	278
-#define	COLUMN	279
-#define	COMMIT	280
-#define	CONSTRAINT	281
-#define	CREATE	282
-#define	CROSS	283
-#define	CURRENT	284
-#define	CURRENT_DATE	285
-#define	CURRENT_TIME	286
-#define	CURRENT_TIMESTAMP	287
-#define	CURRENT_USER	288
-#define	CURSOR	289
-#define	DAY_P	290
-#define	DECIMAL	291
-#define	DECLARE	292
-#define	DEFAULT	293
-#define	DELETE	294
-#define	DESC	295
-#define	DISTINCT	296
-#define	DOUBLE	297
-#define	DROP	298
-#define	ELSE	299
-#define	END_TRANS	300
-#define	EXCEPT	301
-#define	EXECUTE	302
-#define	EXISTS	303
-#define	EXTRACT	304
-#define	FALSE_P	305
-#define	FETCH	306
-#define	FLOAT	307
-#define	FOR	308
-#define	FOREIGN	309
-#define	FROM	310
-#define	FULL	311
-#define	GLOBAL	312
-#define	GRANT	313
-#define	GROUP	314
-#define	HAVING	315
-#define	HOUR_P	316
-#define	IN	317
-#define	INNER_P	318
-#define	INSENSITIVE	319
-#define	INSERT	320
-#define	INTERSECT	321
-#define	INTERVAL	322
-#define	INTO	323
-#define	IS	324
-#define	ISOLATION	325
-#define	JOIN	326
-#define	KEY	327
-#define	LANGUAGE	328
-#define	LEADING	329
-#define	LEFT	330
-#define	LEVEL	331
-#define	LIKE	332
-#define	LOCAL	333
-#define	MATCH	334
-#define	MINUTE_P	335
-#define	MONTH_P	336
-#define	NAMES	337
-#define	NATIONAL	338
-#define	NATURAL	339
-#define	NCHAR	340
-#define	NEXT	341
-#define	NO	342
-#define	NOT	343
-#define	NULLIF	344
-#define	NULL_P	345
-#define	NUMERIC	346
-#define	OF	347
-#define	ON	348
-#define	ONLY	349
-#define	OPTION	350
-#define	OR	351
-#define	ORDER	352
-#define	OUTER_P	353
-#define	PARTIAL	354
-#define	POSITION	355
-#define	PRECISION	356
-#define	PRIMARY	357
-#define	PRIOR	358
-#define	PRIVILEGES	359
-#define	PROCEDURE	360
-#define	PUBLIC	361
-#define	READ	362
-#define	REFERENCES	363
-#define	RELATIVE	364
-#define	REVOKE	365
-#define	RIGHT	366
-#define	ROLLBACK	367
-#define	SCROLL	368
-#define	SECOND_P	369
-#define	SELECT	370
-#define	SET	371
-#define	SUBSTRING	372
-#define	TABLE	373
-#define	TEMP	374
-#define	TEMPORARY	375
-#define	THEN	376
-#define	TIME	377
-#define	TIMESTAMP	378
-#define	TIMEZONE_HOUR	379
-#define	TIMEZONE_MINUTE	380
-#define	TO	381
-#define	TRAILING	382
-#define	TRANSACTION	383
-#define	TRIM	384
-#define	TRUE_P	385
-#define	UNION	386
-#define	UNIQUE	387
-#define	UPDATE	388
-#define	USER	389
-#define	USING	390
-#define	VALUES	391
-#define	VARCHAR	392
-#define	VARYING	393
-#define	VIEW	394
-#define	WHEN	395
-#define	WHERE	396
-#define	WITH	397
-#define	WORK	398
-#define	YEAR_P	399
-#define	ZONE	400
-#define	TRIGGER	401
-#define	COMMITTED	402
-#define	SERIALIZABLE	403
-#define	TYPE_P	404
-#define	ABORT_TRANS	405
-#define	ACCESS	406
-#define	AFTER	407
-#define	AGGREGATE	408
-#define	ANALYZE	409
-#define	BACKWARD	410
-#define	BEFORE	411
-#define	BINARY	412
-#define	CACHE	413
-#define	CLUSTER	414
-#define	COPY	415
-#define	CREATEDB	416
-#define	CREATEUSER	417
-#define	CYCLE	418
-#define	DATABASE	419
-#define	DELIMITERS	420
-#define	DO	421
-#define	EACH	422
-#define	ENCODING	423
-#define	EXCLUSIVE	424
-#define	EXPLAIN	425
-#define	EXTEND	426
-#define	FORWARD	427
-#define	FUNCTION	428
-#define	HANDLER	429
-#define	INCREMENT	430
-#define	INDEX	431
-#define	INHERITS	432
-#define	INSTEAD	433
-#define	ISNULL	434
-#define	LANCOMPILER	435
-#define	LIMIT	436
-#define	LISTEN	437
-#define	LOAD	438
-#define	LOCATION	439
-#define	LOCK_P	440
-#define	MAXVALUE	441
-#define	MINVALUE	442
-#define	MODE	443
-#define	MOVE	444
-#define	NEW	445
-#define	NOCREATEDB	446
-#define	NOCREATEUSER	447
-#define	NONE	448
-#define	NOTHING	449
-#define	NOTIFY	450
-#define	NOTNULL	451
-#define	OFFSET	452
-#define	OIDS	453
-#define	OPERATOR	454
-#define	PASSWORD	455
-#define	PROCEDURAL	456
-#define	RENAME	457
-#define	RESET	458
-#define	RETURNS	459
-#define	ROW	460
-#define	RULE	461
-#define	SEQUENCE	462
-#define	SERIAL	463
-#define	SETOF	464
-#define	SHARE	465
-#define	SHOW	466
-#define	START	467
-#define	STATEMENT	468
-#define	STDIN	469
-#define	STDOUT	470
-#define	TRUSTED	471
-#define	UNLISTEN	472
-#define	UNTIL	473
-#define	VACUUM	474
-#define	VALID	475
-#define	VERBOSE	476
-#define	VERSION	477
-#define	IDENT	478
-#define	SCONST	479
-#define	Op	480
-#define	ICONST	481
-#define	PARAM	482
-#define	FCONST	483
-#define	OP	484
-#define	UMINUS	485
-#define	TYPECAST	486
+#define	ABSOLUTE	258
+#define	ACTION	259
+#define	ADD	260
+#define	ALL	261
+#define	ALTER	262
+#define	AND	263
+#define	ANY	264
+#define	AS	265
+#define	ASC	266
+#define	BEGIN_TRANS	267
+#define	BETWEEN	268
+#define	BOTH	269
+#define	BY	270
+#define	CASCADE	271
+#define	CASE	272
+#define	CAST	273
+#define	CHAR	274
+#define	CHARACTER	275
+#define	CHECK	276
+#define	CLOSE	277
+#define	COALESCE	278
+#define	COLLATE	279
+#define	COLUMN	280
+#define	COMMIT	281
+#define	CONSTRAINT	282
+#define	CREATE	283
+#define	CROSS	284
+#define	CURRENT	285
+#define	CURRENT_DATE	286
+#define	CURRENT_TIME	287
+#define	CURRENT_TIMESTAMP	288
+#define	CURRENT_USER	289
+#define	CURSOR	290
+#define	DAY_P	291
+#define	DECIMAL	292
+#define	DECLARE	293
+#define	DEFAULT	294
+#define	DELETE	295
+#define	DESC	296
+#define	DISTINCT	297
+#define	DOUBLE	298
+#define	DROP	299
+#define	ELSE	300
+#define	END_TRANS	301
+#define	EXCEPT	302
+#define	EXECUTE	303
+#define	EXISTS	304
+#define	EXTRACT	305
+#define	FALSE_P	306
+#define	FETCH	307
+#define	FLOAT	308
+#define	FOR	309
+#define	FOREIGN	310
+#define	FROM	311
+#define	FULL	312
+#define	GLOBAL	313
+#define	GRANT	314
+#define	GROUP	315
+#define	HAVING	316
+#define	HOUR_P	317
+#define	IN	318
+#define	INNER_P	319
+#define	INSENSITIVE	320
+#define	INSERT	321
+#define	INTERSECT	322
+#define	INTERVAL	323
+#define	INTO	324
+#define	IS	325
+#define	ISOLATION	326
+#define	JOIN	327
+#define	KEY	328
+#define	LANGUAGE	329
+#define	LEADING	330
+#define	LEFT	331
+#define	LEVEL	332
+#define	LIKE	333
+#define	LOCAL	334
+#define	MATCH	335
+#define	MINUTE_P	336
+#define	MONTH_P	337
+#define	NAMES	338
+#define	NATIONAL	339
+#define	NATURAL	340
+#define	NCHAR	341
+#define	NEXT	342
+#define	NO	343
+#define	NOT	344
+#define	NULLIF	345
+#define	NULL_P	346
+#define	NUMERIC	347
+#define	OF	348
+#define	ON	349
+#define	ONLY	350
+#define	OPTION	351
+#define	OR	352
+#define	ORDER	353
+#define	OUTER_P	354
+#define	PARTIAL	355
+#define	POSITION	356
+#define	PRECISION	357
+#define	PRIMARY	358
+#define	PRIOR	359
+#define	PRIVILEGES	360
+#define	PROCEDURE	361
+#define	PUBLIC	362
+#define	READ	363
+#define	REFERENCES	364
+#define	RELATIVE	365
+#define	REVOKE	366
+#define	RIGHT	367
+#define	ROLLBACK	368
+#define	SCROLL	369
+#define	SECOND_P	370
+#define	SELECT	371
+#define	SET	372
+#define	SUBSTRING	373
+#define	TABLE	374
+#define	TEMP	375
+#define	TEMPORARY	376
+#define	THEN	377
+#define	TIME	378
+#define	TIMESTAMP	379
+#define	TIMEZONE_HOUR	380
+#define	TIMEZONE_MINUTE	381
+#define	TO	382
+#define	TRAILING	383
+#define	TRANSACTION	384
+#define	TRIM	385
+#define	TRUE_P	386
+#define	UNION	387
+#define	UNIQUE	388
+#define	UPDATE	389
+#define	USER	390
+#define	USING	391
+#define	VALUES	392
+#define	VARCHAR	393
+#define	VARYING	394
+#define	VIEW	395
+#define	WHEN	396
+#define	WHERE	397
+#define	WITH	398
+#define	WORK	399
+#define	YEAR_P	400
+#define	ZONE	401
+#define	TRIGGER	402
+#define	COMMITTED	403
+#define	SERIALIZABLE	404
+#define	TYPE_P	405
+#define	ABORT_TRANS	406
+#define	ACCESS	407
+#define	AFTER	408
+#define	AGGREGATE	409
+#define	ANALYZE	410
+#define	BACKWARD	411
+#define	BEFORE	412
+#define	BINARY	413
+#define	CACHE	414
+#define	CLUSTER	415
+#define	COPY	416
+#define	CREATEDB	417
+#define	CREATEUSER	418
+#define	CYCLE	419
+#define	DATABASE	420
+#define	DELIMITERS	421
+#define	DO	422
+#define	EACH	423
+#define	ENCODING	424
+#define	EXCLUSIVE	425
+#define	EXPLAIN	426
+#define	EXTEND	427
+#define	FORWARD	428
+#define	FUNCTION	429
+#define	HANDLER	430
+#define	INCREMENT	431
+#define	INDEX	432
+#define	INHERITS	433
+#define	INSTEAD	434
+#define	ISNULL	435
+#define	LANCOMPILER	436
+#define	LIMIT	437
+#define	LISTEN	438
+#define	LOAD	439
+#define	LOCATION	440
+#define	LOCK_P	441
+#define	MAXVALUE	442
+#define	MINVALUE	443
+#define	MODE	444
+#define	MOVE	445
+#define	NEW	446
+#define	NOCREATEDB	447
+#define	NOCREATEUSER	448
+#define	NONE	449
+#define	NOTHING	450
+#define	NOTIFY	451
+#define	NOTNULL	452
+#define	OFFSET	453
+#define	OIDS	454
+#define	OPERATOR	455
+#define	PASSWORD	456
+#define	PROCEDURAL	457
+#define	RENAME	458
+#define	RESET	459
+#define	RETURNS	460
+#define	ROW	461
+#define	RULE	462
+#define	SEQUENCE	463
+#define	SERIAL	464
+#define	SETOF	465
+#define	SHARE	466
+#define	SHOW	467
+#define	START	468
+#define	STATEMENT	469
+#define	STDIN	470
+#define	STDOUT	471
+#define	TRUSTED	472
+#define	UNLISTEN	473
+#define	UNTIL	474
+#define	VACUUM	475
+#define	VALID	476
+#define	VERBOSE	477
+#define	VERSION	478
+#define	IDENT	479
+#define	SCONST	480
+#define	Op	481
+#define	ICONST	482
+#define	PARAM	483
+#define	FCONST	484
+#define	OP	485
+#define	UMINUS	486
+#define	TYPECAST	487

extern YYSTYPE yylval;
diff -urbw postgresql-6.5.2/src/backend/parser/parse_func.c postgresql-6.5.2-patched/src/backend/parser/parse_func.c
--- postgresql-6.5.2/src/backend/parser/parse_func.c	Fri Jun 18 00:21:40 1999
+++ postgresql-6.5.2-patched/src/backend/parser/parse_func.c	Wed Mar  1 16:33:53 2000
@@ -601,7 +601,8 @@

if ((aclcheck_result = pg_aclcheck(seqrel, GetPgUserName(),
(((funcid == F_NEXTVAL) || (funcid == F_SETVAL)) ?
-						ACL_WR : ACL_RD)))
+						/* if nextval and setval are atomic, which I don't know, update should be enough */
+						ACL_UP : ACL_RD)))
!= ACLCHECK_OK)
elog(ERROR, "%s.%s: %s",
seqrel, funcname, aclcheck_error_strings[aclcheck_result]);
diff -urbw postgresql-6.5.2/src/backend/rewrite/locks.c postgresql-6.5.2-patched/src/backend/rewrite/locks.c
--- postgresql-6.5.2/src/backend/rewrite/locks.c	Sun Feb 14 00:17:44 1999
+++ postgresql-6.5.2-patched/src/backend/rewrite/locks.c	Wed Mar  1 16:34:20 2000
@@ -228,8 +228,15 @@
case CMD_INSERT:
reqperm = ACL_AP;
break;
+						case CMD_DELETE:
+							reqperm = ACL_DE;
+							break;
+						case CMD_UPDATE:
+							reqperm = ACL_UP;
+							break;
default:
-							reqperm = ACL_WR;
+							/* is it The Right Thing To Do (tm) ? */
+							reqperm = ACL_AP | ACL_DE | ACL_UP;
break;
}
else
diff -urbw postgresql-6.5.2/src/backend/rewrite/rewriteHandler.c postgresql-6.5.2-patched/src/backend/rewrite/rewriteHandler.c
--- postgresql-6.5.2/src/backend/rewrite/rewriteHandler.c	Sun Jul 11 19:54:30 1999
+++ postgresql-6.5.2-patched/src/backend/rewrite/rewriteHandler.c	Wed Mar  1 16:35:01 2000
@@ -2282,8 +2282,15 @@
case CMD_INSERT:
reqperm = ACL_AP;
break;
+				case CMD_DELETE:
+					reqperm = ACL_DE;
+					break;
+				case CMD_UPDATE:
+					reqperm = ACL_UP;
+					break;
default:
-					reqperm = ACL_WR;
+					/* is it The Right Thing To Do (tm) ? */
+					reqperm = ACL_AP | ACL_DE | ACL_UP;
break;
}

diff -urbw postgresql-6.5.2/src/backend/storage/file/fd.c postgresql-6.5.2-patched/src/backend/storage/file/fd.c
diff -urbw postgresql-6.5.2/src/backend/utils/adt/acl.c postgresql-6.5.2-patched/src/backend/utils/adt/acl.c
--- postgresql-6.5.2/src/backend/utils/adt/acl.c	Mon Aug  2 07:24:49 1999
+++ postgresql-6.5.2-patched/src/backend/utils/adt/acl.c	Wed Mar  1 16:35:53 2000
@@ -154,8 +154,11 @@
case ACL_MODE_RD_CHR:
aip->ai_mode |= ACL_RD;
break;
-			case ACL_MODE_WR_CHR:
-				aip->ai_mode |= ACL_WR;
+			case ACL_MODE_DE_CHR:
+				aip->ai_mode |= ACL_DE;
+				break;
+			case ACL_MODE_UP_CHR:
+				aip->ai_mode |= ACL_UP;
break;
case ACL_MODE_RU_CHR:
aip->ai_mode |= ACL_RU;
@@ -272,7 +275,7 @@
if (!aip)
aip = &default_aclitem;

-	p = out = palloc(strlen("group =arwR ") + 1 + NAMEDATALEN);
+	p = out = palloc(strlen("group =arRdu ") + 1 + NAMEDATALEN);
if (!out)
elog(ERROR, "aclitemout: palloc failed");
*p = '\0';
@@ -605,9 +608,8 @@
int			i;
int			l;

-	Assert(strlen(old_privlist) < 5);
-	priv = palloc(5); /* at most "rwaR" */ ;
-
+	Assert(strlen(old_privlist) < 6);
+	priv = palloc(6); /* at most "arduR" */ ;
if (old_privlist == NULL || old_privlist[0] == '\0')
{
priv[0] = new_priv;
@@ -619,7 +621,7 @@

l = strlen(old_privlist);

-	if (l == 4)
+	if (l == 5)
{							/* can't add any more privileges */
return priv;
}
diff -urbw postgresql-6.5.2/src/include/utils/acl.h postgresql-6.5.2-patched/src/include/utils/acl.h
--- postgresql-6.5.2/src/include/utils/acl.h	Fri Jul 30 19:07:22 1999
+++ postgresql-6.5.2-patched/src/include/utils/acl.h	Wed Mar  1 16:40:50 2000
@@ -54,9 +54,10 @@
#define ACL_NO			0		/* no permissions */
#define ACL_AP			(1<<0)	/* append */
#define ACL_RD			(1<<1)	/* read */
-#define ACL_WR			(1<<2)	/* write (append/delete/replace) */
-#define ACL_RU			(1<<3)	/* place rules */
-#define N_ACL_MODES		4
+#define ACL_DE			(1<<2)	/* delete */
+#define ACL_UP			(1<<3)	/* update/replace */
+#define ACL_RU			(1<<4)	/* place rules */
+#define N_ACL_MODES		5

#define ACL_MODECHG_ADD			1
#define ACL_MODECHG_DEL			2
@@ -65,7 +66,8 @@
/* change this line if you want to set the default acl permission  */
#define ACL_WORLD_DEFAULT		(ACL_NO)
/* #define		ACL_WORLD_DEFAULT		(ACL_RD|ACL_WR|ACL_AP|ACL_RU) */
-#define ACL_OWNER_DEFAULT		(ACL_RD|ACL_WR|ACL_AP|ACL_RU)
+
+#define ACL_OWNER_DEFAULT		(ACL_AP|ACL_RD|ACL_RU|ACL_DE|ACL_UP)

/*
* AclItem
@@ -118,10 +120,12 @@
#define ACL_MODECHG_ADD_CHR		'+'
#define ACL_MODECHG_DEL_CHR		'-'
#define ACL_MODECHG_EQL_CHR		'='
-#define ACL_MODE_STR			"arwR"	/* list of valid characters */
+
+#define ACL_MODE_STR			"arduR"	 /* list of valid characters */
#define ACL_MODE_AP_CHR			'a'
#define ACL_MODE_RD_CHR			'r'
-#define ACL_MODE_WR_CHR			'w'
+#define ACL_MODE_DE_CHR			'd'
+#define ACL_MODE_UP_CHR			'u'
#define ACL_MODE_RU_CHR			'R'

/* result codes for pg_aclcheck */

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian writes:

OK, this was a good point. Were did we leave this, folks?

I was going to do some extensive work on the privilege system, but if you
guys always postpone beta for a month just a day before it was supposed to
be I'll never know when to start.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Nevertheless, you should probably consider installing the patch.

Bruce Momjian writes:

OK, this was a good point. Were did we leave this, folks?

Hi,

first I'm sorry to not fill the form, I'm too lazy, and it's not platform
nor version dependent AFAIK.

I recently posted a question (on Feb 23rd) to pgsql-sql concerning the
fact that update and insert are considered the same thing when you modify
permissions with grant and revoke. (Maybe it was the wrong place to post
it.)

for example a "grant delete" also grants "update" which is completely
wrong. More importantly the user is not informed, and this could lead to
VERY IMPORTANT SECURITY PROBLEMS, like someone who should only be able to
update existing records, have the permission to delete all records...

I've read postgresql documentation, especially the grant and revoke
manpages, and I've found no mention of this bug, which is IMHO a Big
Mistake (tm).

attached to this message you'll find a patch for version 6.5.2 wich
differentiate delete and update, because before they were considered as
"write". The patch only modifies .c .y and .h files, but no documentation.

the new acl rights look like: arRdu
a for append
r for read
R for rules
d for delete
u for update

instead of: arwR
a for append
r for read
w for update AND delete
R for rules

This patch seems to work at least with what I've tested, you'll find a
test session at the end of this message.

I hope this patch will help and that it will be easy to incorporate it in
7.0, which I haven't the time to do for now.

And for the bug report I posted on Feb 23rd on "drop user" which keeps the
user's acl in the database, and the deleted user id being reused, I've not
done anything, but I consider this a major problem. Please consider it for
a next version.

Because I'm not an expert, I suggest you remove gram.c before applying the
patch, in order for this file to be generated again from gram.y, but maybe
this is not necessary.

I'd be very pleased if some people could test this more than I can,
because I don't use postgresql intensively with special permissions.

I'm not sure for some parts of the patch, especially in execMain.c
so if a postgresql hacker could examine it, this would be fine.

dump of test session:
---------------------

------- CUT -------

template1=> create database db;
CREATEDB
template1=> create user john;
CREATE USER
template1=> \connect db
connecting to new database: db
db=> create table t (id INT4, name TEXT);
CREATE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | |
+----------+--------------------------+
db=> grant all on t to john;
CHANGE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=arduR"} |
+----------+--------------------------+
db=> \connect db john
connecting to new database: db as user: john
db=> insert into t (id, name) values (1, 'xxx');
INSERT 18560 1
db=> update t set name = 'yyy' where id=1;
UPDATE 1
db=> select * from t;
id|name
--+----
1|yyy
(1 row)

db=> delete from t;
DELETE 1
db=> select * from t;
id|name
--+----
(0 rows)

db=> insert into t (id, name) values (1, 'xxx');
INSERT 18561 1
db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke update on t from john;
CHANGE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=ardR"} |
+----------+--------------------------+
db=> \connect db john;
connecting to new database: db as user: john
db=> insert into t (id, name) values (2, 'yyy');
INSERT 18592 1
db=> update t set name='modified by john' where id=2;
ERROR: t: Permission denied.
db=> delete from t where id=2;
DELETE 1
db=> select * from t;
id|name
--+----
1|xxx
(1 row)

db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke insert on t from john;
CHANGE
db=> \connect db john;
connecting to new database: db as user: john
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=rdR"} |
+----------+--------------------------+
db=> insert into t (id, name) values (3, 'I try to insert something');
ERROR: t: Permission denied.
db=> delete from t;
DELETE 1
db=> select * from t;
id|name
--+----
(0 rows)

db=> \connect db postgres
connecting to new database: db as user: postgres
db=> insert into t (id, name) values (1, 'xxx');
INSERT 18624 1
db=> \connect db john;
connecting to new database: db as user: john
db=> update t set name='john' where id =1;
ERROR: t: Permission denied.
db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke delete on t from john;
CHANGE
db=> grant update on t to john;
CHANGE
db=> \connect db john;
connecting to new database: db as user: john
db=> delete from t;
ERROR: t: Permission denied.
db=> update t set name='john' where id=1;
UPDATE 1
db=> select * from t;
id|name
--+----
1|john
(1 row)

------- CUT -------

Thank you for reading.

bye,

Jerome ALET - alet@unice.fr - http://cortex.unice.fr/~jerome
Faculte de Medecine de Nice - http://noe.unice.fr - Tel: 04 93 37 76 30
28 Avenue de Valombrose - 06107 NICE Cedex 2 - FRANCE

Content-Description: the 6.5.2 patch

diff -urbw postgresql-6.5.2/src/backend/catalog/aclchk.c postgresql-6.5.2-patched/src/backend/catalog/aclchk.c
--- postgresql-6.5.2/src/backend/catalog/aclchk.c	Mon Aug  2 07:56:53 1999
+++ postgresql-6.5.2-patched/src/backend/catalog/aclchk.c	Wed Mar  1 16:39:44 2000
@@ -381,7 +381,7 @@
* pg_database table, there is still additional permissions
* checking in dbcommands.c
*/
-		if ((mode & ACL_WR) || (mode & ACL_AP))
+		if (mode & ACL_AP)
return ACLCHECK_OK;
}

@@ -390,7 +390,7 @@
* pg_shadow.usecatupd is set.	(This is to let superusers protect
* themselves from themselves.)
*/
-	if (((mode & ACL_WR) || (mode & ACL_AP)) &&
+	if ((mode & ACL_AP) &&
!allowSystemTableMods && IsSystemRelationName(relname) &&
!((Form_pg_shadow) GETSTRUCT(tuple))->usecatupd)
{
diff -urbw postgresql-6.5.2/src/backend/commands/command.c postgresql-6.5.2-patched/src/backend/commands/command.c
--- postgresql-6.5.2/src/backend/commands/command.c	Mon Aug  2 07:56:57 1999
+++ postgresql-6.5.2-patched/src/backend/commands/command.c	Wed Mar  1 16:30:23 2000
@@ -524,7 +524,9 @@
if (lockstmt->mode == AccessShareLock)
aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), ACL_RD);
else
-		aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), ACL_WR);
+		/* do we really need to have all these permissions at the same time ? */
+		/* shouldn't we test lockstmt->mode first ? */
+		aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), (ACL_AP | ACL_DE | ACL_UP));

if (aclresult != ACLCHECK_OK)
elog(ERROR, "LOCK TABLE: permission denied");
diff -urbw postgresql-6.5.2/src/backend/commands/copy.c postgresql-6.5.2-patched/src/backend/commands/copy.c
--- postgresql-6.5.2/src/backend/commands/copy.c	Sat Jul  3 02:32:39 1999
+++ postgresql-6.5.2-patched/src/backend/commands/copy.c	Wed Mar  1 16:30:35 2000
@@ -242,7 +242,8 @@
FILE	   *fp;
Relation	rel;
extern char *UserName;		/* defined in global.c */
-	const AclMode required_access = from ? ACL_WR : ACL_RD;
+	/* why should we need other permissions than APPEND ? */
+	const AclMode required_access = from ? ACL_AP : ACL_RD;
int			result;

rel = heap_openr(relname);
diff -urbw postgresql-6.5.2/src/backend/commands/sequence.c postgresql-6.5.2-patched/src/backend/commands/sequence.c
--- postgresql-6.5.2/src/backend/commands/sequence.c	Mon Aug  2 07:56:59 1999
+++ postgresql-6.5.2-patched/src/backend/commands/sequence.c	Wed Mar  1 16:31:05 2000
@@ -314,7 +314,8 @@
Form_pg_sequence seq;

#ifndef NO_SECURITY
-	if (pg_aclcheck(seqname, getpgusername(), ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than UPDATE permission ? */
+	if (pg_aclcheck(seqname, getpgusername(), ACL_UP) != ACLCHECK_OK)
elog(ERROR, "%s.setval: you don't have permissions to set sequence %s",
seqname, seqname);
#endif
diff -urbw postgresql-6.5.2/src/backend/commands/user.c postgresql-6.5.2-patched/src/backend/commands/user.c
--- postgresql-6.5.2/src/backend/commands/user.c	Mon Aug  2 07:56:59 1999
+++ postgresql-6.5.2-patched/src/backend/commands/user.c	Wed Mar  1 16:31:38 2000
@@ -115,7 +115,7 @@
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR | ACL_AP) != ACLCHECK_OK)
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_AP | ACL_DE | ACL_UP) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "defineUser: user \"%s\" does not have SELECT and INSERT privilege for \"%s\"",
@@ -227,7 +227,8 @@
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than UPDATE ? */
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_UP) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "alterUser: user \"%s\" does not have SELECT and UPDATE privilege for \"%s\"",
@@ -329,11 +330,12 @@
BeginTransactionBlock();

/*
-	 * Make sure the user attempting to create a user can delete from the
+	 * Make sure the user attempting to delete a user can delete from the
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than DELETE ? */
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_DE) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "removeUser: user \"%s\" does not have SELECT and DELETE privilege for \"%s\"",
diff -urbw postgresql-6.5.2/src/backend/executor/execMain.c postgresql-6.5.2-patched/src/backend/executor/execMain.c
--- postgresql-6.5.2/src/backend/executor/execMain.c	Thu Jun 17 17:15:49 1999
+++ postgresql-6.5.2-patched/src/backend/executor/execMain.c	Wed Mar  1 18:31:31 2000
@@ -464,14 +464,16 @@
switch (operation)
{
case CMD_INSERT:
-					ok = ((aclcheck_result = CHECK(ACL_AP)) == ACLCHECK_OK) ||
-						((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
+					ok = ((aclcheck_result = CHECK(ACL_AP)) == ACLCHECK_OK);
opstr = "append";
break;
case CMD_DELETE:
+					ok = ((aclcheck_result = CHECK(ACL_DE)) == ACLCHECK_OK);
+					opstr = "delete";
+					break;
case CMD_UPDATE:
-					ok = ((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
-					opstr = "write";
+					ok = ((aclcheck_result = CHECK(ACL_UP)) == ACLCHECK_OK);
+					opstr = "update";
break;
default:
elog(ERROR, "ExecCheckPerms: bogus operation %d",
@@ -508,8 +510,9 @@
StrNCpy(rname.data,
((Form_pg_class) GETSTRUCT(htup))->relname.data,
NAMEDATALEN);
-			ok = ((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
-			opstr = "write";
+			/* is it the right thing to do ? */
+			ok = ((aclcheck_result = CHECK((ACL_AP | ACL_DE | ACL_UP))) == ACLCHECK_OK);
+			opstr = "write";	/* unused ? */
if (!ok)
elog(ERROR, "%s: %s", rname.data, aclcheck_error_strings[aclcheck_result]);
}
diff -urbw postgresql-6.5.2/src/backend/parser/gram.y postgresql-6.5.2-patched/src/backend/parser/gram.y
--- postgresql-6.5.2/src/backend/parser/gram.y	Tue Sep 14 08:07:35 1999
+++ postgresql-6.5.2-patched/src/backend/parser/gram.y	Wed Mar  1 16:33:34 2000
@@ -1694,11 +1694,11 @@

privileges:  ALL PRIVILEGES
{
-				 $$ = aclmakepriv("rwaR",0);
+				 $$ = aclmakepriv("raduR",0);
}
| ALL
{
-				 $$ = aclmakepriv("rwaR",0);
+				 $$ = aclmakepriv("raduR",0);
}
| operation_commalist
{
@@ -1726,11 +1726,11 @@
}
| UPDATE
{
-						$$ = ACL_MODE_WR_CHR;
+						$$ = ACL_MODE_UP_CHR;
}
| DELETE
{
-						$$ = ACL_MODE_WR_CHR;
+						$$ = ACL_MODE_DE_CHR;
}
| RULE
{
diff -urbw postgresql-6.5.2/src/backend/parser/parse.h postgresql-6.5.2-patched/src/backend/parser/parse.h
--- postgresql-6.5.2/src/backend/parser/parse.h	Thu Sep 16 02:23:39 1999
+++ postgresql-6.5.2-patched/src/backend/parser/parse.h	Wed Mar  1 18:34:46 2000
@@ -29,236 +29,236 @@
RuleStmt			*rstmt;
InsertStmt			*astmt;
} YYSTYPE;
-#define	ABSOLUTE	257
-#define	ACTION	258
-#define	ADD	259
-#define	ALL	260
-#define	ALTER	261
-#define	AND	262
-#define	ANY	263
-#define	AS	264
-#define	ASC	265
-#define	BEGIN_TRANS	266
-#define	BETWEEN	267
-#define	BOTH	268
-#define	BY	269
-#define	CASCADE	270
-#define	CASE	271
-#define	CAST	272
-#define	CHAR	273
-#define	CHARACTER	274
-#define	CHECK	275
-#define	CLOSE	276
-#define	COALESCE	277
-#define	COLLATE	278
-#define	COLUMN	279
-#define	COMMIT	280
-#define	CONSTRAINT	281
-#define	CREATE	282
-#define	CROSS	283
-#define	CURRENT	284
-#define	CURRENT_DATE	285
-#define	CURRENT_TIME	286
-#define	CURRENT_TIMESTAMP	287
-#define	CURRENT_USER	288
-#define	CURSOR	289
-#define	DAY_P	290
-#define	DECIMAL	291
-#define	DECLARE	292
-#define	DEFAULT	293
-#define	DELETE	294
-#define	DESC	295
-#define	DISTINCT	296
-#define	DOUBLE	297
-#define	DROP	298
-#define	ELSE	299
-#define	END_TRANS	300
-#define	EXCEPT	301
-#define	EXECUTE	302
-#define	EXISTS	303
-#define	EXTRACT	304
-#define	FALSE_P	305
-#define	FETCH	306
-#define	FLOAT	307
-#define	FOR	308
-#define	FOREIGN	309
-#define	FROM	310
-#define	FULL	311
-#define	GLOBAL	312
-#define	GRANT	313
-#define	GROUP	314
-#define	HAVING	315
-#define	HOUR_P	316
-#define	IN	317
-#define	INNER_P	318
-#define	INSENSITIVE	319
-#define	INSERT	320
-#define	INTERSECT	321
-#define	INTERVAL	322
-#define	INTO	323
-#define	IS	324
-#define	ISOLATION	325
-#define	JOIN	326
-#define	KEY	327
-#define	LANGUAGE	328
-#define	LEADING	329
-#define	LEFT	330
-#define	LEVEL	331
-#define	LIKE	332
-#define	LOCAL	333
-#define	MATCH	334
-#define	MINUTE_P	335
-#define	MONTH_P	336
-#define	NAMES	337
-#define	NATIONAL	338
-#define	NATURAL	339
-#define	NCHAR	340
-#define	NEXT	341
-#define	NO	342
-#define	NOT	343
-#define	NULLIF	344
-#define	NULL_P	345
-#define	NUMERIC	346
-#define	OF	347
-#define	ON	348
-#define	ONLY	349
-#define	OPTION	350
-#define	OR	351
-#define	ORDER	352
-#define	OUTER_P	353
-#define	PARTIAL	354
-#define	POSITION	355
-#define	PRECISION	356
-#define	PRIMARY	357
-#define	PRIOR	358
-#define	PRIVILEGES	359
-#define	PROCEDURE	360
-#define	PUBLIC	361
-#define	READ	362
-#define	REFERENCES	363
-#define	RELATIVE	364
-#define	REVOKE	365
-#define	RIGHT	366
-#define	ROLLBACK	367
-#define	SCROLL	368
-#define	SECOND_P	369
-#define	SELECT	370
-#define	SET	371
-#define	SUBSTRING	372
-#define	TABLE	373
-#define	TEMP	374
-#define	TEMPORARY	375
-#define	THEN	376
-#define	TIME	377
-#define	TIMESTAMP	378
-#define	TIMEZONE_HOUR	379
-#define	TIMEZONE_MINUTE	380
-#define	TO	381
-#define	TRAILING	382
-#define	TRANSACTION	383
-#define	TRIM	384
-#define	TRUE_P	385
-#define	UNION	386
-#define	UNIQUE	387
-#define	UPDATE	388
-#define	USER	389
-#define	USING	390
-#define	VALUES	391
-#define	VARCHAR	392
-#define	VARYING	393
-#define	VIEW	394
-#define	WHEN	395
-#define	WHERE	396
-#define	WITH	397
-#define	WORK	398
-#define	YEAR_P	399
-#define	ZONE	400
-#define	TRIGGER	401
-#define	COMMITTED	402
-#define	SERIALIZABLE	403
-#define	TYPE_P	404
-#define	ABORT_TRANS	405
-#define	ACCESS	406
-#define	AFTER	407
-#define	AGGREGATE	408
-#define	ANALYZE	409
-#define	BACKWARD	410
-#define	BEFORE	411
-#define	BINARY	412
-#define	CACHE	413
-#define	CLUSTER	414
-#define	COPY	415
-#define	CREATEDB	416
-#define	CREATEUSER	417
-#define	CYCLE	418
-#define	DATABASE	419
-#define	DELIMITERS	420
-#define	DO	421
-#define	EACH	422
-#define	ENCODING	423
-#define	EXCLUSIVE	424
-#define	EXPLAIN	425
-#define	EXTEND	426
-#define	FORWARD	427
-#define	FUNCTION	428
-#define	HANDLER	429
-#define	INCREMENT	430
-#define	INDEX	431
-#define	INHERITS	432
-#define	INSTEAD	433
-#define	ISNULL	434
-#define	LANCOMPILER	435
-#define	LIMIT	436
-#define	LISTEN	437
-#define	LOAD	438
-#define	LOCATION	439
-#define	LOCK_P	440
-#define	MAXVALUE	441
-#define	MINVALUE	442
-#define	MODE	443
-#define	MOVE	444
-#define	NEW	445
-#define	NOCREATEDB	446
-#define	NOCREATEUSER	447
-#define	NONE	448
-#define	NOTHING	449
-#define	NOTIFY	450
-#define	NOTNULL	451
-#define	OFFSET	452
-#define	OIDS	453
-#define	OPERATOR	454
-#define	PASSWORD	455
-#define	PROCEDURAL	456
-#define	RENAME	457
-#define	RESET	458
-#define	RETURNS	459
-#define	ROW	460
-#define	RULE	461
-#define	SEQUENCE	462
-#define	SERIAL	463
-#define	SETOF	464
-#define	SHARE	465
-#define	SHOW	466
-#define	START	467
-#define	STATEMENT	468
-#define	STDIN	469
-#define	STDOUT	470
-#define	TRUSTED	471
-#define	UNLISTEN	472
-#define	UNTIL	473
-#define	VACUUM	474
-#define	VALID	475
-#define	VERBOSE	476
-#define	VERSION	477
-#define	IDENT	478
-#define	SCONST	479
-#define	Op	480
-#define	ICONST	481
-#define	PARAM	482
-#define	FCONST	483
-#define	OP	484
-#define	UMINUS	485
-#define	TYPECAST	486
+#define	ABSOLUTE	258
+#define	ACTION	259
+#define	ADD	260
+#define	ALL	261
+#define	ALTER	262
+#define	AND	263
+#define	ANY	264
+#define	AS	265
+#define	ASC	266
+#define	BEGIN_TRANS	267
+#define	BETWEEN	268
+#define	BOTH	269
+#define	BY	270
+#define	CASCADE	271
+#define	CASE	272
+#define	CAST	273
+#define	CHAR	274
+#define	CHARACTER	275
+#define	CHECK	276
+#define	CLOSE	277
+#define	COALESCE	278
+#define	COLLATE	279
+#define	COLUMN	280
+#define	COMMIT	281
+#define	CONSTRAINT	282
+#define	CREATE	283
+#define	CROSS	284
+#define	CURRENT	285
+#define	CURRENT_DATE	286
+#define	CURRENT_TIME	287
+#define	CURRENT_TIMESTAMP	288
+#define	CURRENT_USER	289
+#define	CURSOR	290
+#define	DAY_P	291
+#define	DECIMAL	292
+#define	DECLARE	293
+#define	DEFAULT	294
+#define	DELETE	295
+#define	DESC	296
+#define	DISTINCT	297
+#define	DOUBLE	298
+#define	DROP	299
+#define	ELSE	300
+#define	END_TRANS	301
+#define	EXCEPT	302
+#define	EXECUTE	303
+#define	EXISTS	304
+#define	EXTRACT	305
+#define	FALSE_P	306
+#define	FETCH	307
+#define	FLOAT	308
+#define	FOR	309
+#define	FOREIGN	310
+#define	FROM	311
+#define	FULL	312
+#define	GLOBAL	313
+#define	GRANT	314
+#define	GROUP	315
+#define	HAVING	316
+#define	HOUR_P	317
+#define	IN	318
+#define	INNER_P	319
+#define	INSENSITIVE	320
+#define	INSERT	321
+#define	INTERSECT	322
+#define	INTERVAL	323
+#define	INTO	324
+#define	IS	325
+#define	ISOLATION	326
+#define	JOIN	327
+#define	KEY	328
+#define	LANGUAGE	329
+#define	LEADING	330
+#define	LEFT	331
+#define	LEVEL	332
+#define	LIKE	333
+#define	LOCAL	334
+#define	MATCH	335
+#define	MINUTE_P	336
+#define	MONTH_P	337
+#define	NAMES	338
+#define	NATIONAL	339
+#define	NATURAL	340
+#define	NCHAR	341
+#define	NEXT	342
+#define	NO	343
+#define	NOT	344
+#define	NULLIF	345
+#define	NULL_P	346
+#define	NUMERIC	347
+#define	OF	348
+#define	ON	349
+#define	ONLY	350
+#define	OPTION	351
+#define	OR	352
+#define	ORDER	353
+#define	OUTER_P	354
+#define	PARTIAL	355
+#define	POSITION	356
+#define	PRECISION	357
+#define	PRIMARY	358
+#define	PRIOR	359
+#define	PRIVILEGES	360
+#define	PROCEDURE	361
+#define	PUBLIC	362
+#define	READ	363
+#define	REFERENCES	364
+#define	RELATIVE	365
+#define	REVOKE	366
+#define	RIGHT	367
+#define	ROLLBACK	368
+#define	SCROLL	369
+#define	SECOND_P	370
+#define	SELECT	371
+#define	SET	372
+#define	SUBSTRING	373
+#define	TABLE	374
+#define	TEMP	375
+#define	TEMPORARY	376
+#define	THEN	377
+#define	TIME	378
+#define	TIMESTAMP	379
+#define	TIMEZONE_HOUR	380
+#define	TIMEZONE_MINUTE	381
+#define	TO	382
+#define	TRAILING	383
+#define	TRANSACTION	384
+#define	TRIM	385
+#define	TRUE_P	386
+#define	UNION	387
+#define	UNIQUE	388
+#define	UPDATE	389
+#define	USER	390
+#define	USING	391
+#define	VALUES	392
+#define	VARCHAR	393
+#define	VARYING	394
+#define	VIEW	395
+#define	WHEN	396
+#define	WHERE	397
+#define	WITH	398
+#define	WORK	399
+#define	YEAR_P	400
+#define	ZONE	401
+#define	TRIGGER	402
+#define	COMMITTED	403
+#define	SERIALIZABLE	404
+#define	TYPE_P	405
+#define	ABORT_TRANS	406
+#define	ACCESS	407
+#define	AFTER	408
+#define	AGGREGATE	409
+#define	ANALYZE	410
+#define	BACKWARD	411
+#define	BEFORE	412
+#define	BINARY	413
+#define	CACHE	414
+#define	CLUSTER	415
+#define	COPY	416
+#define	CREATEDB	417
+#define	CREATEUSER	418
+#define	CYCLE	419
+#define	DATABASE	420
+#define	DELIMITERS	421
+#define	DO	422
+#define	EACH	423
+#define	ENCODING	424
+#define	EXCLUSIVE	425
+#define	EXPLAIN	426
+#define	EXTEND	427
+#define	FORWARD	428
+#define	FUNCTION	429
+#define	HANDLER	430
+#define	INCREMENT	431
+#define	INDEX	432
+#define	INHERITS	433
+#define	INSTEAD	434
+#define	ISNULL	435
+#define	LANCOMPILER	436
+#define	LIMIT	437
+#define	LISTEN	438
+#define	LOAD	439
+#define	LOCATION	440
+#define	LOCK_P	441
+#define	MAXVALUE	442
+#define	MINVALUE	443
+#define	MODE	444
+#define	MOVE	445
+#define	NEW	446
+#define	NOCREATEDB	447
+#define	NOCREATEUSER	448
+#define	NONE	449
+#define	NOTHING	450
+#define	NOTIFY	451
+#define	NOTNULL	452
+#define	OFFSET	453
+#define	OIDS	454
+#define	OPERATOR	455
+#define	PASSWORD	456
+#define	PROCEDURAL	457
+#define	RENAME	458
+#define	RESET	459
+#define	RETURNS	460
+#define	ROW	461
+#define	RULE	462
+#define	SEQUENCE	463
+#define	SERIAL	464
+#define	SETOF	465
+#define	SHARE	466
+#define	SHOW	467
+#define	START	468
+#define	STATEMENT	469
+#define	STDIN	470
+#define	STDOUT	471
+#define	TRUSTED	472
+#define	UNLISTEN	473
+#define	UNTIL	474
+#define	VACUUM	475
+#define	VALID	476
+#define	VERBOSE	477
+#define	VERSION	478
+#define	IDENT	479
+#define	SCONST	480
+#define	Op	481
+#define	ICONST	482
+#define	PARAM	483
+#define	FCONST	484
+#define	OP	485
+#define	UMINUS	486
+#define	TYPECAST	487

extern YYSTYPE yylval;
diff -urbw postgresql-6.5.2/src/backend/parser/parse_func.c postgresql-6.5.2-patched/src/backend/parser/parse_func.c
--- postgresql-6.5.2/src/backend/parser/parse_func.c	Fri Jun 18 00:21:40 1999
+++ postgresql-6.5.2-patched/src/backend/parser/parse_func.c	Wed Mar  1 16:33:53 2000
@@ -601,7 +601,8 @@

if ((aclcheck_result = pg_aclcheck(seqrel, GetPgUserName(),
(((funcid == F_NEXTVAL) || (funcid == F_SETVAL)) ?
-						ACL_WR : ACL_RD)))
+						/* if nextval and setval are atomic, which I don't know, update should be enough */
+						ACL_UP : ACL_RD)))
!= ACLCHECK_OK)
elog(ERROR, "%s.%s: %s",
seqrel, funcname, aclcheck_error_strings[aclcheck_result]);
diff -urbw postgresql-6.5.2/src/backend/rewrite/locks.c postgresql-6.5.2-patched/src/backend/rewrite/locks.c
--- postgresql-6.5.2/src/backend/rewrite/locks.c	Sun Feb 14 00:17:44 1999
+++ postgresql-6.5.2-patched/src/backend/rewrite/locks.c	Wed Mar  1 16:34:20 2000
@@ -228,8 +228,15 @@
case CMD_INSERT:
reqperm = ACL_AP;
break;
+						case CMD_DELETE:
+							reqperm = ACL_DE;
+							break;
+						case CMD_UPDATE:
+							reqperm = ACL_UP;
+							break;
default:
-							reqperm = ACL_WR;
+							/* is it The Right Thing To Do (tm) ? */
+							reqperm = ACL_AP | ACL_DE | ACL_UP;
break;
}
else
diff -urbw postgresql-6.5.2/src/backend/rewrite/rewriteHandler.c postgresql-6.5.2-patched/src/backend/rewrite/rewriteHandler.c
--- postgresql-6.5.2/src/backend/rewrite/rewriteHandler.c	Sun Jul 11 19:54:30 1999
+++ postgresql-6.5.2-patched/src/backend/rewrite/rewriteHandler.c	Wed Mar  1 16:35:01 2000
@@ -2282,8 +2282,15 @@
case CMD_INSERT:
reqperm = ACL_AP;
break;
+				case CMD_DELETE:
+					reqperm = ACL_DE;
+					break;
+				case CMD_UPDATE:
+					reqperm = ACL_UP;
+					break;
default:
-					reqperm = ACL_WR;
+					/* is it The Right Thing To Do (tm) ? */
+					reqperm = ACL_AP | ACL_DE | ACL_UP;
break;
}

diff -urbw postgresql-6.5.2/src/backend/storage/file/fd.c postgresql-6.5.2-patched/src/backend/storage/file/fd.c
diff -urbw postgresql-6.5.2/src/backend/utils/adt/acl.c postgresql-6.5.2-patched/src/backend/utils/adt/acl.c
--- postgresql-6.5.2/src/backend/utils/adt/acl.c	Mon Aug  2 07:24:49 1999
+++ postgresql-6.5.2-patched/src/backend/utils/adt/acl.c	Wed Mar  1 16:35:53 2000
@@ -154,8 +154,11 @@
case ACL_MODE_RD_CHR:
aip->ai_mode |= ACL_RD;
break;
-			case ACL_MODE_WR_CHR:
-				aip->ai_mode |= ACL_WR;
+			case ACL_MODE_DE_CHR:
+				aip->ai_mode |= ACL_DE;
+				break;
+			case ACL_MODE_UP_CHR:
+				aip->ai_mode |= ACL_UP;
break;
case ACL_MODE_RU_CHR:
aip->ai_mode |= ACL_RU;
@@ -272,7 +275,7 @@
if (!aip)
aip = &default_aclitem;

-	p = out = palloc(strlen("group =arwR ") + 1 + NAMEDATALEN);
+	p = out = palloc(strlen("group =arRdu ") + 1 + NAMEDATALEN);
if (!out)
elog(ERROR, "aclitemout: palloc failed");
*p = '\0';
@@ -605,9 +608,8 @@
int			i;
int			l;

-	Assert(strlen(old_privlist) < 5);
-	priv = palloc(5); /* at most "rwaR" */ ;
-
+	Assert(strlen(old_privlist) < 6);
+	priv = palloc(6); /* at most "arduR" */ ;
if (old_privlist == NULL || old_privlist[0] == '\0')
{
priv[0] = new_priv;
@@ -619,7 +621,7 @@

l = strlen(old_privlist);

-	if (l == 4)
+	if (l == 5)
{							/* can't add any more privileges */
return priv;
}
diff -urbw postgresql-6.5.2/src/include/utils/acl.h postgresql-6.5.2-patched/src/include/utils/acl.h
--- postgresql-6.5.2/src/include/utils/acl.h	Fri Jul 30 19:07:22 1999
+++ postgresql-6.5.2-patched/src/include/utils/acl.h	Wed Mar  1 16:40:50 2000
@@ -54,9 +54,10 @@
#define ACL_NO			0		/* no permissions */
#define ACL_AP			(1<<0)	/* append */
#define ACL_RD			(1<<1)	/* read */
-#define ACL_WR			(1<<2)	/* write (append/delete/replace) */
-#define ACL_RU			(1<<3)	/* place rules */
-#define N_ACL_MODES		4
+#define ACL_DE			(1<<2)	/* delete */
+#define ACL_UP			(1<<3)	/* update/replace */
+#define ACL_RU			(1<<4)	/* place rules */
+#define N_ACL_MODES		5

#define ACL_MODECHG_ADD			1
#define ACL_MODECHG_DEL			2
@@ -65,7 +66,8 @@
/* change this line if you want to set the default acl permission  */
#define ACL_WORLD_DEFAULT		(ACL_NO)
/* #define		ACL_WORLD_DEFAULT		(ACL_RD|ACL_WR|ACL_AP|ACL_RU) */
-#define ACL_OWNER_DEFAULT		(ACL_RD|ACL_WR|ACL_AP|ACL_RU)
+
+#define ACL_OWNER_DEFAULT		(ACL_AP|ACL_RD|ACL_RU|ACL_DE|ACL_UP)

/*
* AclItem
@@ -118,10 +120,12 @@
#define ACL_MODECHG_ADD_CHR		'+'
#define ACL_MODECHG_DEL_CHR		'-'
#define ACL_MODECHG_EQL_CHR		'='
-#define ACL_MODE_STR			"arwR"	/* list of valid characters */
+
+#define ACL_MODE_STR			"arduR"	 /* list of valid characters */
#define ACL_MODE_AP_CHR			'a'
#define ACL_MODE_RD_CHR			'r'
-#define ACL_MODE_WR_CHR			'w'
+#define ACL_MODE_DE_CHR			'd'
+#define ACL_MODE_UP_CHR			'u'
#define ACL_MODE_RU_CHR			'R'

/* result codes for pg_aclcheck */

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

I tried to apply this patch to the current tree, but unfortunately,
changes made in permission handling prevent it from being applied.

Seems we were too far into testing to apply this long ago, and now we
are too far away from the original patch to apply it now. If you are
still intersted, we would like to get this patch against the current
source tree.

Sorry this got lost in the patch process for so long.

Hi,

first I'm sorry to not fill the form, I'm too lazy, and it's not platform
nor version dependent AFAIK.

I recently posted a question (on Feb 23rd) to pgsql-sql concerning the
fact that update and insert are considered the same thing when you modify
permissions with grant and revoke. (Maybe it was the wrong place to post
it.)

for example a "grant delete" also grants "update" which is completely
wrong. More importantly the user is not informed, and this could lead to
VERY IMPORTANT SECURITY PROBLEMS, like someone who should only be able to
update existing records, have the permission to delete all records...

I've read postgresql documentation, especially the grant and revoke
manpages, and I've found no mention of this bug, which is IMHO a Big
Mistake (tm).

attached to this message you'll find a patch for version 6.5.2 wich
differentiate delete and update, because before they were considered as
"write". The patch only modifies .c .y and .h files, but no documentation.

the new acl rights look like: arRdu
a for append
r for read
R for rules
d for delete
u for update

instead of: arwR
a for append
r for read
w for update AND delete
R for rules

This patch seems to work at least with what I've tested, you'll find a
test session at the end of this message.

I hope this patch will help and that it will be easy to incorporate it in
7.0, which I haven't the time to do for now.

And for the bug report I posted on Feb 23rd on "drop user" which keeps the
user's acl in the database, and the deleted user id being reused, I've not
done anything, but I consider this a major problem. Please consider it for
a next version.

Because I'm not an expert, I suggest you remove gram.c before applying the
patch, in order for this file to be generated again from gram.y, but maybe
this is not necessary.

I'd be very pleased if some people could test this more than I can,
because I don't use postgresql intensively with special permissions.

I'm not sure for some parts of the patch, especially in execMain.c
so if a postgresql hacker could examine it, this would be fine.

dump of test session:
---------------------

------- CUT -------

template1=> create database db;
CREATEDB
template1=> create user john;
CREATE USER
template1=> \connect db
connecting to new database: db
db=> create table t (id INT4, name TEXT);
CREATE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | |
+----------+--------------------------+
db=> grant all on t to john;
CHANGE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=arduR"} |
+----------+--------------------------+
db=> \connect db john
connecting to new database: db as user: john
db=> insert into t (id, name) values (1, 'xxx');
INSERT 18560 1
db=> update t set name = 'yyy' where id=1;
UPDATE 1
db=> select * from t;
id|name
--+----
1|yyy
(1 row)

db=> delete from t;
DELETE 1
db=> select * from t;
id|name
--+----
(0 rows)

db=> insert into t (id, name) values (1, 'xxx');
INSERT 18561 1
db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke update on t from john;
CHANGE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=ardR"} |
+----------+--------------------------+
db=> \connect db john;
connecting to new database: db as user: john
db=> insert into t (id, name) values (2, 'yyy');
INSERT 18592 1
db=> update t set name='modified by john' where id=2;
ERROR: t: Permission denied.
db=> delete from t where id=2;
DELETE 1
db=> select * from t;
id|name
--+----
1|xxx
(1 row)

db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke insert on t from john;
CHANGE
db=> \connect db john;
connecting to new database: db as user: john
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=rdR"} |
+----------+--------------------------+
db=> insert into t (id, name) values (3, 'I try to insert something');
ERROR: t: Permission denied.
db=> delete from t;
DELETE 1
db=> select * from t;
id|name
--+----
(0 rows)

db=> \connect db postgres
connecting to new database: db as user: postgres
db=> insert into t (id, name) values (1, 'xxx');
INSERT 18624 1
db=> \connect db john;
connecting to new database: db as user: john
db=> update t set name='john' where id =1;
ERROR: t: Permission denied.
db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke delete on t from john;
CHANGE
db=> grant update on t to john;
CHANGE
db=> \connect db john;
connecting to new database: db as user: john
db=> delete from t;
ERROR: t: Permission denied.
db=> update t set name='john' where id=1;
UPDATE 1
db=> select * from t;
id|name
--+----
1|john
(1 row)

------- CUT -------

Thank you for reading.

bye,

Jerome ALET - alet@unice.fr - http://cortex.unice.fr/~jerome
Faculte de Medecine de Nice - http://noe.unice.fr - Tel: 04 93 37 76 30
28 Avenue de Valombrose - 06107 NICE Cedex 2 - FRANCE

Content-Description: the 6.5.2 patch

diff -urbw postgresql-6.5.2/src/backend/catalog/aclchk.c postgresql-6.5.2-patched/src/backend/catalog/aclchk.c
--- postgresql-6.5.2/src/backend/catalog/aclchk.c	Mon Aug  2 07:56:53 1999
+++ postgresql-6.5.2-patched/src/backend/catalog/aclchk.c	Wed Mar  1 16:39:44 2000
@@ -381,7 +381,7 @@
* pg_database table, there is still additional permissions
* checking in dbcommands.c
*/
-		if ((mode & ACL_WR) || (mode & ACL_AP))
+		if (mode & ACL_AP)
return ACLCHECK_OK;
}

@@ -390,7 +390,7 @@
* pg_shadow.usecatupd is set.	(This is to let superusers protect
* themselves from themselves.)
*/
-	if (((mode & ACL_WR) || (mode & ACL_AP)) &&
+	if ((mode & ACL_AP) &&
!allowSystemTableMods && IsSystemRelationName(relname) &&
!((Form_pg_shadow) GETSTRUCT(tuple))->usecatupd)
{
diff -urbw postgresql-6.5.2/src/backend/commands/command.c postgresql-6.5.2-patched/src/backend/commands/command.c
--- postgresql-6.5.2/src/backend/commands/command.c	Mon Aug  2 07:56:57 1999
+++ postgresql-6.5.2-patched/src/backend/commands/command.c	Wed Mar  1 16:30:23 2000
@@ -524,7 +524,9 @@
if (lockstmt->mode == AccessShareLock)
aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), ACL_RD);
else
-		aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), ACL_WR);
+		/* do we really need to have all these permissions at the same time ? */
+		/* shouldn't we test lockstmt->mode first ? */
+		aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), (ACL_AP | ACL_DE | ACL_UP));

if (aclresult != ACLCHECK_OK)
elog(ERROR, "LOCK TABLE: permission denied");
diff -urbw postgresql-6.5.2/src/backend/commands/copy.c postgresql-6.5.2-patched/src/backend/commands/copy.c
--- postgresql-6.5.2/src/backend/commands/copy.c	Sat Jul  3 02:32:39 1999
+++ postgresql-6.5.2-patched/src/backend/commands/copy.c	Wed Mar  1 16:30:35 2000
@@ -242,7 +242,8 @@
FILE	   *fp;
Relation	rel;
extern char *UserName;		/* defined in global.c */
-	const AclMode required_access = from ? ACL_WR : ACL_RD;
+	/* why should we need other permissions than APPEND ? */
+	const AclMode required_access = from ? ACL_AP : ACL_RD;
int			result;

rel = heap_openr(relname);
diff -urbw postgresql-6.5.2/src/backend/commands/sequence.c postgresql-6.5.2-patched/src/backend/commands/sequence.c
--- postgresql-6.5.2/src/backend/commands/sequence.c	Mon Aug  2 07:56:59 1999
+++ postgresql-6.5.2-patched/src/backend/commands/sequence.c	Wed Mar  1 16:31:05 2000
@@ -314,7 +314,8 @@
Form_pg_sequence seq;

#ifndef NO_SECURITY
-	if (pg_aclcheck(seqname, getpgusername(), ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than UPDATE permission ? */
+	if (pg_aclcheck(seqname, getpgusername(), ACL_UP) != ACLCHECK_OK)
elog(ERROR, "%s.setval: you don't have permissions to set sequence %s",
seqname, seqname);
#endif
diff -urbw postgresql-6.5.2/src/backend/commands/user.c postgresql-6.5.2-patched/src/backend/commands/user.c
--- postgresql-6.5.2/src/backend/commands/user.c	Mon Aug  2 07:56:59 1999
+++ postgresql-6.5.2-patched/src/backend/commands/user.c	Wed Mar  1 16:31:38 2000
@@ -115,7 +115,7 @@
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR | ACL_AP) != ACLCHECK_OK)
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_AP | ACL_DE | ACL_UP) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "defineUser: user \"%s\" does not have SELECT and INSERT privilege for \"%s\"",
@@ -227,7 +227,8 @@
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than UPDATE ? */
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_UP) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "alterUser: user \"%s\" does not have SELECT and UPDATE privilege for \"%s\"",
@@ -329,11 +330,12 @@
BeginTransactionBlock();

/*
-	 * Make sure the user attempting to create a user can delete from the
+	 * Make sure the user attempting to delete a user can delete from the
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than DELETE ? */
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_DE) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "removeUser: user \"%s\" does not have SELECT and DELETE privilege for \"%s\"",
diff -urbw postgresql-6.5.2/src/backend/executor/execMain.c postgresql-6.5.2-patched/src/backend/executor/execMain.c
--- postgresql-6.5.2/src/backend/executor/execMain.c	Thu Jun 17 17:15:49 1999
+++ postgresql-6.5.2-patched/src/backend/executor/execMain.c	Wed Mar  1 18:31:31 2000
@@ -464,14 +464,16 @@
switch (operation)
{
case CMD_INSERT:
-					ok = ((aclcheck_result = CHECK(ACL_AP)) == ACLCHECK_OK) ||
-						((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
+					ok = ((aclcheck_result = CHECK(ACL_AP)) == ACLCHECK_OK);
opstr = "append";
break;
case CMD_DELETE:
+					ok = ((aclcheck_result = CHECK(ACL_DE)) == ACLCHECK_OK);
+					opstr = "delete";
+					break;
case CMD_UPDATE:
-					ok = ((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
-					opstr = "write";
+					ok = ((aclcheck_result = CHECK(ACL_UP)) == ACLCHECK_OK);
+					opstr = "update";
break;
default:
elog(ERROR, "ExecCheckPerms: bogus operation %d",
@@ -508,8 +510,9 @@
StrNCpy(rname.data,
((Form_pg_class) GETSTRUCT(htup))->relname.data,
NAMEDATALEN);
-			ok = ((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
-			opstr = "write";
+			/* is it the right thing to do ? */
+			ok = ((aclcheck_result = CHECK((ACL_AP | ACL_DE | ACL_UP))) == ACLCHECK_OK);
+			opstr = "write";	/* unused ? */
if (!ok)
elog(ERROR, "%s: %s", rname.data, aclcheck_error_strings[aclcheck_result]);
}
diff -urbw postgresql-6.5.2/src/backend/parser/gram.y postgresql-6.5.2-patched/src/backend/parser/gram.y
--- postgresql-6.5.2/src/backend/parser/gram.y	Tue Sep 14 08:07:35 1999
+++ postgresql-6.5.2-patched/src/backend/parser/gram.y	Wed Mar  1 16:33:34 2000
@@ -1694,11 +1694,11 @@

privileges:  ALL PRIVILEGES
{
-				 $$ = aclmakepriv("rwaR",0);
+				 $$ = aclmakepriv("raduR",0);
}
| ALL
{
-				 $$ = aclmakepriv("rwaR",0);
+				 $$ = aclmakepriv("raduR",0);
}
| operation_commalist
{
@@ -1726,11 +1726,11 @@
}
| UPDATE
{
-						$$ = ACL_MODE_WR_CHR;
+						$$ = ACL_MODE_UP_CHR;
}
| DELETE
{
-						$$ = ACL_MODE_WR_CHR;
+						$$ = ACL_MODE_DE_CHR;
}
| RULE
{
diff -urbw postgresql-6.5.2/src/backend/parser/parse.h postgresql-6.5.2-patched/src/backend/parser/parse.h
--- postgresql-6.5.2/src/backend/parser/parse.h	Thu Sep 16 02:23:39 1999
+++ postgresql-6.5.2-patched/src/backend/parser/parse.h	Wed Mar  1 18:34:46 2000
@@ -29,236 +29,236 @@
RuleStmt			*rstmt;
InsertStmt			*astmt;
} YYSTYPE;
-#define	ABSOLUTE	257
-#define	ACTION	258
-#define	ADD	259
-#define	ALL	260
-#define	ALTER	261
-#define	AND	262
-#define	ANY	263
-#define	AS	264
-#define	ASC	265
-#define	BEGIN_TRANS	266
-#define	BETWEEN	267
-#define	BOTH	268
-#define	BY	269
-#define	CASCADE	270
-#define	CASE	271
-#define	CAST	272
-#define	CHAR	273
-#define	CHARACTER	274
-#define	CHECK	275
-#define	CLOSE	276
-#define	COALESCE	277
-#define	COLLATE	278
-#define	COLUMN	279
-#define	COMMIT	280
-#define	CONSTRAINT	281
-#define	CREATE	282
-#define	CROSS	283
-#define	CURRENT	284
-#define	CURRENT_DATE	285
-#define	CURRENT_TIME	286
-#define	CURRENT_TIMESTAMP	287
-#define	CURRENT_USER	288
-#define	CURSOR	289
-#define	DAY_P	290
-#define	DECIMAL	291
-#define	DECLARE	292
-#define	DEFAULT	293
-#define	DELETE	294
-#define	DESC	295
-#define	DISTINCT	296
-#define	DOUBLE	297
-#define	DROP	298
-#define	ELSE	299
-#define	END_TRANS	300
-#define	EXCEPT	301
-#define	EXECUTE	302
-#define	EXISTS	303
-#define	EXTRACT	304
-#define	FALSE_P	305
-#define	FETCH	306
-#define	FLOAT	307
-#define	FOR	308
-#define	FOREIGN	309
-#define	FROM	310
-#define	FULL	311
-#define	GLOBAL	312
-#define	GRANT	313
-#define	GROUP	314
-#define	HAVING	315
-#define	HOUR_P	316
-#define	IN	317
-#define	INNER_P	318
-#define	INSENSITIVE	319
-#define	INSERT	320
-#define	INTERSECT	321
-#define	INTERVAL	322
-#define	INTO	323
-#define	IS	324
-#define	ISOLATION	325
-#define	JOIN	326
-#define	KEY	327
-#define	LANGUAGE	328
-#define	LEADING	329
-#define	LEFT	330
-#define	LEVEL	331
-#define	LIKE	332
-#define	LOCAL	333
-#define	MATCH	334
-#define	MINUTE_P	335
-#define	MONTH_P	336
-#define	NAMES	337
-#define	NATIONAL	338
-#define	NATURAL	339
-#define	NCHAR	340
-#define	NEXT	341
-#define	NO	342
-#define	NOT	343
-#define	NULLIF	344
-#define	NULL_P	345
-#define	NUMERIC	346
-#define	OF	347
-#define	ON	348
-#define	ONLY	349
-#define	OPTION	350
-#define	OR	351
-#define	ORDER	352
-#define	OUTER_P	353
-#define	PARTIAL	354
-#define	POSITION	355
-#define	PRECISION	356
-#define	PRIMARY	357
-#define	PRIOR	358
-#define	PRIVILEGES	359
-#define	PROCEDURE	360
-#define	PUBLIC	361
-#define	READ	362
-#define	REFERENCES	363
-#define	RELATIVE	364
-#define	REVOKE	365
-#define	RIGHT	366
-#define	ROLLBACK	367
-#define	SCROLL	368
-#define	SECOND_P	369
-#define	SELECT	370
-#define	SET	371
-#define	SUBSTRING	372
-#define	TABLE	373
-#define	TEMP	374
-#define	TEMPORARY	375
-#define	THEN	376
-#define	TIME	377
-#define	TIMESTAMP	378
-#define	TIMEZONE_HOUR	379
-#define	TIMEZONE_MINUTE	380
-#define	TO	381
-#define	TRAILING	382
-#define	TRANSACTION	383
-#define	TRIM	384
-#define	TRUE_P	385
-#define	UNION	386
-#define	UNIQUE	387
-#define	UPDATE	388
-#define	USER	389
-#define	USING	390
-#define	VALUES	391
-#define	VARCHAR	392
-#define	VARYING	393
-#define	VIEW	394
-#define	WHEN	395
-#define	WHERE	396
-#define	WITH	397
-#define	WORK	398
-#define	YEAR_P	399
-#define	ZONE	400
-#define	TRIGGER	401
-#define	COMMITTED	402
-#define	SERIALIZABLE	403
-#define	TYPE_P	404
-#define	ABORT_TRANS	405
-#define	ACCESS	406
-#define	AFTER	407
-#define	AGGREGATE	408
-#define	ANALYZE	409
-#define	BACKWARD	410
-#define	BEFORE	411
-#define	BINARY	412
-#define	CACHE	413
-#define	CLUSTER	414
-#define	COPY	415
-#define	CREATEDB	416
-#define	CREATEUSER	417
-#define	CYCLE	418
-#define	DATABASE	419
-#define	DELIMITERS	420
-#define	DO	421
-#define	EACH	422
-#define	ENCODING	423
-#define	EXCLUSIVE	424
-#define	EXPLAIN	425
-#define	EXTEND	426
-#define	FORWARD	427
-#define	FUNCTION	428
-#define	HANDLER	429
-#define	INCREMENT	430
-#define	INDEX	431
-#define	INHERITS	432
-#define	INSTEAD	433
-#define	ISNULL	434
-#define	LANCOMPILER	435
-#define	LIMIT	436
-#define	LISTEN	437
-#define	LOAD	438
-#define	LOCATION	439
-#define	LOCK_P	440
-#define	MAXVALUE	441
-#define	MINVALUE	442
-#define	MODE	443
-#define	MOVE	444
-#define	NEW	445
-#define	NOCREATEDB	446
-#define	NOCREATEUSER	447
-#define	NONE	448
-#define	NOTHING	449
-#define	NOTIFY	450
-#define	NOTNULL	451
-#define	OFFSET	452
-#define	OIDS	453
-#define	OPERATOR	454
-#define	PASSWORD	455
-#define	PROCEDURAL	456
-#define	RENAME	457
-#define	RESET	458
-#define	RETURNS	459
-#define	ROW	460
-#define	RULE	461
-#define	SEQUENCE	462
-#define	SERIAL	463
-#define	SETOF	464
-#define	SHARE	465
-#define	SHOW	466
-#define	START	467
-#define	STATEMENT	468
-#define	STDIN	469
-#define	STDOUT	470
-#define	TRUSTED	471
-#define	UNLISTEN	472
-#define	UNTIL	473
-#define	VACUUM	474
-#define	VALID	475
-#define	VERBOSE	476
-#define	VERSION	477
-#define	IDENT	478
-#define	SCONST	479
-#define	Op	480
-#define	ICONST	481
-#define	PARAM	482
-#define	FCONST	483
-#define	OP	484
-#define	UMINUS	485
-#define	TYPECAST	486
+#define	ABSOLUTE	258
+#define	ACTION	259
+#define	ADD	260
+#define	ALL	261
+#define	ALTER	262
+#define	AND	263
+#define	ANY	264
+#define	AS	265
+#define	ASC	266
+#define	BEGIN_TRANS	267
+#define	BETWEEN	268
+#define	BOTH	269
+#define	BY	270
+#define	CASCADE	271
+#define	CASE	272
+#define	CAST	273
+#define	CHAR	274
+#define	CHARACTER	275
+#define	CHECK	276
+#define	CLOSE	277
+#define	COALESCE	278
+#define	COLLATE	279
+#define	COLUMN	280
+#define	COMMIT	281
+#define	CONSTRAINT	282
+#define	CREATE	283
+#define	CROSS	284
+#define	CURRENT	285
+#define	CURRENT_DATE	286
+#define	CURRENT_TIME	287
+#define	CURRENT_TIMESTAMP	288
+#define	CURRENT_USER	289
+#define	CURSOR	290
+#define	DAY_P	291
+#define	DECIMAL	292
+#define	DECLARE	293
+#define	DEFAULT	294
+#define	DELETE	295
+#define	DESC	296
+#define	DISTINCT	297
+#define	DOUBLE	298
+#define	DROP	299
+#define	ELSE	300
+#define	END_TRANS	301
+#define	EXCEPT	302
+#define	EXECUTE	303
+#define	EXISTS	304
+#define	EXTRACT	305
+#define	FALSE_P	306
+#define	FETCH	307
+#define	FLOAT	308
+#define	FOR	309
+#define	FOREIGN	310
+#define	FROM	311
+#define	FULL	312
+#define	GLOBAL	313
+#define	GRANT	314
+#define	GROUP	315
+#define	HAVING	316
+#define	HOUR_P	317
+#define	IN	318
+#define	INNER_P	319
+#define	INSENSITIVE	320
+#define	INSERT	321
+#define	INTERSECT	322
+#define	INTERVAL	323
+#define	INTO	324
+#define	IS	325
+#define	ISOLATION	326
+#define	JOIN	327
+#define	KEY	328
+#define	LANGUAGE	329
+#define	LEADING	330
+#define	LEFT	331
+#define	LEVEL	332
+#define	LIKE	333
+#define	LOCAL	334
+#define	MATCH	335
+#define	MINUTE_P	336
+#define	MONTH_P	337
+#define	NAMES	338
+#define	NATIONAL	339
+#define	NATURAL	340
+#define	NCHAR	341
+#define	NEXT	342
+#define	NO	343
+#define	NOT	344
+#define	NULLIF	345
+#define	NULL_P	346
+#define	NUMERIC	347
+#define	OF	348
+#define	ON	349
+#define	ONLY	350
+#define	OPTION	351
+#define	OR	352
+#define	ORDER	353
+#define	OUTER_P	354
+#define	PARTIAL	355
+#define	POSITION	356
+#define	PRECISION	357
+#define	PRIMARY	358
+#define	PRIOR	359
+#define	PRIVILEGES	360
+#define	PROCEDURE	361
+#define	PUBLIC	362
+#define	READ	363
+#define	REFERENCES	364
+#define	RELATIVE	365
+#define	REVOKE	366
+#define	RIGHT	367
+#define	ROLLBACK	368
+#define	SCROLL	369
+#define	SECOND_P	370
+#define	SELECT	371
+#define	SET	372
+#define	SUBSTRING	373
+#define	TABLE	374
+#define	TEMP	375
+#define	TEMPORARY	376
+#define	THEN	377
+#define	TIME	378
+#define	TIMESTAMP	379
+#define	TIMEZONE_HOUR	380
+#define	TIMEZONE_MINUTE	381
+#define	TO	382
+#define	TRAILING	383
+#define	TRANSACTION	384
+#define	TRIM	385
+#define	TRUE_P	386
+#define	UNION	387
+#define	UNIQUE	388
+#define	UPDATE	389
+#define	USER	390
+#define	USING	391
+#define	VALUES	392
+#define	VARCHAR	393
+#define	VARYING	394
+#define	VIEW	395
+#define	WHEN	396
+#define	WHERE	397
+#define	WITH	398
+#define	WORK	399
+#define	YEAR_P	400
+#define	ZONE	401
+#define	TRIGGER	402
+#define	COMMITTED	403
+#define	SERIALIZABLE	404
+#define	TYPE_P	405
+#define	ABORT_TRANS	406
+#define	ACCESS	407
+#define	AFTER	408
+#define	AGGREGATE	409
+#define	ANALYZE	410
+#define	BACKWARD	411
+#define	BEFORE	412
+#define	BINARY	413
+#define	CACHE	414
+#define	CLUSTER	415
+#define	COPY	416
+#define	CREATEDB	417
+#define	CREATEUSER	418
+#define	CYCLE	419
+#define	DATABASE	420
+#define	DELIMITERS	421
+#define	DO	422
+#define	EACH	423
+#define	ENCODING	424
+#define	EXCLUSIVE	425
+#define	EXPLAIN	426
+#define	EXTEND	427
+#define	FORWARD	428
+#define	FUNCTION	429
+#define	HANDLER	430
+#define	INCREMENT	431
+#define	INDEX	432
+#define	INHERITS	433
+#define	INSTEAD	434
+#define	ISNULL	435
+#define	LANCOMPILER	436
+#define	LIMIT	437
+#define	LISTEN	438
+#define	LOAD	439
+#define	LOCATION	440
+#define	LOCK_P	441
+#define	MAXVALUE	442
+#define	MINVALUE	443
+#define	MODE	444
+#define	MOVE	445
+#define	NEW	446
+#define	NOCREATEDB	447
+#define	NOCREATEUSER	448
+#define	NONE	449
+#define	NOTHING	450
+#define	NOTIFY	451
+#define	NOTNULL	452
+#define	OFFSET	453
+#define	OIDS	454
+#define	OPERATOR	455
+#define	PASSWORD	456
+#define	PROCEDURAL	457
+#define	RENAME	458
+#define	RESET	459
+#define	RETURNS	460
+#define	ROW	461
+#define	RULE	462
+#define	SEQUENCE	463
+#define	SERIAL	464
+#define	SETOF	465
+#define	SHARE	466
+#define	SHOW	467
+#define	START	468
+#define	STATEMENT	469
+#define	STDIN	470
+#define	STDOUT	471
+#define	TRUSTED	472
+#define	UNLISTEN	473
+#define	UNTIL	474
+#define	VACUUM	475
+#define	VALID	476
+#define	VERBOSE	477
+#define	VERSION	478
+#define	IDENT	479
+#define	SCONST	480
+#define	Op	481
+#define	ICONST	482
+#define	PARAM	483
+#define	FCONST	484
+#define	OP	485
+#define	UMINUS	486
+#define	TYPECAST	487

extern YYSTYPE yylval;
diff -urbw postgresql-6.5.2/src/backend/parser/parse_func.c postgresql-6.5.2-patched/src/backend/parser/parse_func.c
--- postgresql-6.5.2/src/backend/parser/parse_func.c	Fri Jun 18 00:21:40 1999
+++ postgresql-6.5.2-patched/src/backend/parser/parse_func.c	Wed Mar  1 16:33:53 2000
@@ -601,7 +601,8 @@

if ((aclcheck_result = pg_aclcheck(seqrel, GetPgUserName(),
(((funcid == F_NEXTVAL) || (funcid == F_SETVAL)) ?
-						ACL_WR : ACL_RD)))
+						/* if nextval and setval are atomic, which I don't know, update should be enough */
+						ACL_UP : ACL_RD)))
!= ACLCHECK_OK)
elog(ERROR, "%s.%s: %s",
seqrel, funcname, aclcheck_error_strings[aclcheck_result]);
diff -urbw postgresql-6.5.2/src/backend/rewrite/locks.c postgresql-6.5.2-patched/src/backend/rewrite/locks.c
--- postgresql-6.5.2/src/backend/rewrite/locks.c	Sun Feb 14 00:17:44 1999
+++ postgresql-6.5.2-patched/src/backend/rewrite/locks.c	Wed Mar  1 16:34:20 2000
@@ -228,8 +228,15 @@
case CMD_INSERT:
reqperm = ACL_AP;
break;
+						case CMD_DELETE:
+							reqperm = ACL_DE;
+							break;
+						case CMD_UPDATE:
+							reqperm = ACL_UP;
+							break;
default:
-							reqperm = ACL_WR;
+							/* is it The Right Thing To Do (tm) ? */
+							reqperm = ACL_AP | ACL_DE | ACL_UP;
break;
}
else
diff -urbw postgresql-6.5.2/src/backend/rewrite/rewriteHandler.c postgresql-6.5.2-patched/src/backend/rewrite/rewriteHandler.c
--- postgresql-6.5.2/src/backend/rewrite/rewriteHandler.c	Sun Jul 11 19:54:30 1999
+++ postgresql-6.5.2-patched/src/backend/rewrite/rewriteHandler.c	Wed Mar  1 16:35:01 2000
@@ -2282,8 +2282,15 @@
case CMD_INSERT:
reqperm = ACL_AP;
break;
+				case CMD_DELETE:
+					reqperm = ACL_DE;
+					break;
+				case CMD_UPDATE:
+					reqperm = ACL_UP;
+					break;
default:
-					reqperm = ACL_WR;
+					/* is it The Right Thing To Do (tm) ? */
+					reqperm = ACL_AP | ACL_DE | ACL_UP;
break;
}

diff -urbw postgresql-6.5.2/src/backend/storage/file/fd.c postgresql-6.5.2-patched/src/backend/storage/file/fd.c
diff -urbw postgresql-6.5.2/src/backend/utils/adt/acl.c postgresql-6.5.2-patched/src/backend/utils/adt/acl.c
--- postgresql-6.5.2/src/backend/utils/adt/acl.c	Mon Aug  2 07:24:49 1999
+++ postgresql-6.5.2-patched/src/backend/utils/adt/acl.c	Wed Mar  1 16:35:53 2000
@@ -154,8 +154,11 @@
case ACL_MODE_RD_CHR:
aip->ai_mode |= ACL_RD;
break;
-			case ACL_MODE_WR_CHR:
-				aip->ai_mode |= ACL_WR;
+			case ACL_MODE_DE_CHR:
+				aip->ai_mode |= ACL_DE;
+				break;
+			case ACL_MODE_UP_CHR:
+				aip->ai_mode |= ACL_UP;
break;
case ACL_MODE_RU_CHR:
aip->ai_mode |= ACL_RU;
@@ -272,7 +275,7 @@
if (!aip)
aip = &default_aclitem;

-	p = out = palloc(strlen("group =arwR ") + 1 + NAMEDATALEN);
+	p = out = palloc(strlen("group =arRdu ") + 1 + NAMEDATALEN);
if (!out)
elog(ERROR, "aclitemout: palloc failed");
*p = '\0';
@@ -605,9 +608,8 @@
int			i;
int			l;

-	Assert(strlen(old_privlist) < 5);
-	priv = palloc(5); /* at most "rwaR" */ ;
-
+	Assert(strlen(old_privlist) < 6);
+	priv = palloc(6); /* at most "arduR" */ ;
if (old_privlist == NULL || old_privlist[0] == '\0')
{
priv[0] = new_priv;
@@ -619,7 +621,7 @@

l = strlen(old_privlist);

-	if (l == 4)
+	if (l == 5)
{							/* can't add any more privileges */
return priv;
}
diff -urbw postgresql-6.5.2/src/include/utils/acl.h postgresql-6.5.2-patched/src/include/utils/acl.h
--- postgresql-6.5.2/src/include/utils/acl.h	Fri Jul 30 19:07:22 1999
+++ postgresql-6.5.2-patched/src/include/utils/acl.h	Wed Mar  1 16:40:50 2000
@@ -54,9 +54,10 @@
#define ACL_NO			0		/* no permissions */
#define ACL_AP			(1<<0)	/* append */
#define ACL_RD			(1<<1)	/* read */
-#define ACL_WR			(1<<2)	/* write (append/delete/replace) */
-#define ACL_RU			(1<<3)	/* place rules */
-#define N_ACL_MODES		4
+#define ACL_DE			(1<<2)	/* delete */
+#define ACL_UP			(1<<3)	/* update/replace */
+#define ACL_RU			(1<<4)	/* place rules */
+#define N_ACL_MODES		5

#define ACL_MODECHG_ADD			1
#define ACL_MODECHG_DEL			2
@@ -65,7 +66,8 @@
/* change this line if you want to set the default acl permission  */
#define ACL_WORLD_DEFAULT		(ACL_NO)
/* #define		ACL_WORLD_DEFAULT		(ACL_RD|ACL_WR|ACL_AP|ACL_RU) */
-#define ACL_OWNER_DEFAULT		(ACL_RD|ACL_WR|ACL_AP|ACL_RU)
+
+#define ACL_OWNER_DEFAULT		(ACL_AP|ACL_RD|ACL_RU|ACL_DE|ACL_UP)

/*
* AclItem
@@ -118,10 +120,12 @@
#define ACL_MODECHG_ADD_CHR		'+'
#define ACL_MODECHG_DEL_CHR		'-'
#define ACL_MODECHG_EQL_CHR		'='
-#define ACL_MODE_STR			"arwR"	/* list of valid characters */
+
+#define ACL_MODE_STR			"arduR"	 /* list of valid characters */
#define ACL_MODE_AP_CHR			'a'
#define ACL_MODE_RD_CHR			'r'
-#define ACL_MODE_WR_CHR			'w'
+#define ACL_MODE_DE_CHR			'd'
+#define ACL_MODE_UP_CHR			'u'
#define ACL_MODE_RU_CHR			'R'

/* result codes for pg_aclcheck */

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Mon, 2 Oct 2000, Bruce Momjian wrote:

I tried to apply this patch to the current tree, but unfortunately,
changes made in permission handling prevent it from being applied.

Seems we were too far into testing to apply this long ago, and now we
are too far away from the original patch to apply it now. If you are
still intersted, we would like to get this patch against the current
source tree.

Hi,

of course I'm still interested.

however, as you've already been warned months ago, I don't have any time
to do it again for 7.x, I'm sorry. Maybe next year or around December, but
now it's impossible.

sorry, but not my fault.

bye,

Jerome Alet

This has been fixed in 7.2beta:

* -Permission to DELETE table also allows UPDATE (Peter E)

---------------------------------------------------------------------------

Hi,

first I'm sorry to not fill the form, I'm too lazy, and it's not platform
nor version dependent AFAIK.

I recently posted a question (on Feb 23rd) to pgsql-sql concerning the
fact that update and insert are considered the same thing when you modify
permissions with grant and revoke. (Maybe it was the wrong place to post
it.)

for example a "grant delete" also grants "update" which is completely
wrong. More importantly the user is not informed, and this could lead to
VERY IMPORTANT SECURITY PROBLEMS, like someone who should only be able to
update existing records, have the permission to delete all records...

I've read postgresql documentation, especially the grant and revoke
manpages, and I've found no mention of this bug, which is IMHO a Big
Mistake (tm).

attached to this message you'll find a patch for version 6.5.2 wich
differentiate delete and update, because before they were considered as
"write". The patch only modifies .c .y and .h files, but no documentation.

the new acl rights look like: arRdu
a for append
r for read
R for rules
d for delete
u for update

instead of: arwR
a for append
r for read
w for update AND delete
R for rules

This patch seems to work at least with what I've tested, you'll find a
test session at the end of this message.

I hope this patch will help and that it will be easy to incorporate it in
7.0, which I haven't the time to do for now.

And for the bug report I posted on Feb 23rd on "drop user" which keeps the
user's acl in the database, and the deleted user id being reused, I've not
done anything, but I consider this a major problem. Please consider it for
a next version.

Because I'm not an expert, I suggest you remove gram.c before applying the
patch, in order for this file to be generated again from gram.y, but maybe
this is not necessary.

I'd be very pleased if some people could test this more than I can,
because I don't use postgresql intensively with special permissions.

I'm not sure for some parts of the patch, especially in execMain.c
so if a postgresql hacker could examine it, this would be fine.

dump of test session:
---------------------

------- CUT -------

template1=> create database db;
CREATEDB
template1=> create user john;
CREATE USER
template1=> \connect db
connecting to new database: db
db=> create table t (id INT4, name TEXT);
CREATE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | |
+----------+--------------------------+
db=> grant all on t to john;
CHANGE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=arduR"} |
+----------+--------------------------+
db=> \connect db john
connecting to new database: db as user: john
db=> insert into t (id, name) values (1, 'xxx');
INSERT 18560 1
db=> update t set name = 'yyy' where id=1;
UPDATE 1
db=> select * from t;
id|name
--+----
1|yyy
(1 row)

db=> delete from t;
DELETE 1
db=> select * from t;
id|name
--+----
(0 rows)

db=> insert into t (id, name) values (1, 'xxx');
INSERT 18561 1
db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke update on t from john;
CHANGE
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=ardR"} |
+----------+--------------------------+
db=> \connect db john;
connecting to new database: db as user: john
db=> insert into t (id, name) values (2, 'yyy');
INSERT 18592 1
db=> update t set name='modified by john' where id=2;
ERROR: t: Permission denied.
db=> delete from t where id=2;
DELETE 1
db=> select * from t;
id|name
--+----
1|xxx
(1 row)

db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke insert on t from john;
CHANGE
db=> \connect db john;
connecting to new database: db as user: john
db=> \z
Database = db
+----------+--------------------------+
| Relation | Grant/Revoke Permissions |
+----------+--------------------------+
| t | {"=","john=rdR"} |
+----------+--------------------------+
db=> insert into t (id, name) values (3, 'I try to insert something');
ERROR: t: Permission denied.
db=> delete from t;
DELETE 1
db=> select * from t;
id|name
--+----
(0 rows)

db=> \connect db postgres
connecting to new database: db as user: postgres
db=> insert into t (id, name) values (1, 'xxx');
INSERT 18624 1
db=> \connect db john;
connecting to new database: db as user: john
db=> update t set name='john' where id =1;
ERROR: t: Permission denied.
db=> \connect db postgres
connecting to new database: db as user: postgres
db=> revoke delete on t from john;
CHANGE
db=> grant update on t to john;
CHANGE
db=> \connect db john;
connecting to new database: db as user: john
db=> delete from t;
ERROR: t: Permission denied.
db=> update t set name='john' where id=1;
UPDATE 1
db=> select * from t;
id|name
--+----
1|john
(1 row)

------- CUT -------

Thank you for reading.

bye,

Jerome ALET - alet@unice.fr - http://cortex.unice.fr/~jerome
Faculte de Medecine de Nice - http://noe.unice.fr - Tel: 04 93 37 76 30
28 Avenue de Valombrose - 06107 NICE Cedex 2 - FRANCE

Content-Description: the 6.5.2 patch

diff -urbw postgresql-6.5.2/src/backend/catalog/aclchk.c postgresql-6.5.2-patched/src/backend/catalog/aclchk.c
--- postgresql-6.5.2/src/backend/catalog/aclchk.c	Mon Aug  2 07:56:53 1999
+++ postgresql-6.5.2-patched/src/backend/catalog/aclchk.c	Wed Mar  1 16:39:44 2000
@@ -381,7 +381,7 @@
* pg_database table, there is still additional permissions
* checking in dbcommands.c
*/
-		if ((mode & ACL_WR) || (mode & ACL_AP))
+		if (mode & ACL_AP)
return ACLCHECK_OK;
}

@@ -390,7 +390,7 @@
* pg_shadow.usecatupd is set.	(This is to let superusers protect
* themselves from themselves.)
*/
-	if (((mode & ACL_WR) || (mode & ACL_AP)) &&
+	if ((mode & ACL_AP) &&
!allowSystemTableMods && IsSystemRelationName(relname) &&
!((Form_pg_shadow) GETSTRUCT(tuple))->usecatupd)
{
diff -urbw postgresql-6.5.2/src/backend/commands/command.c postgresql-6.5.2-patched/src/backend/commands/command.c
--- postgresql-6.5.2/src/backend/commands/command.c	Mon Aug  2 07:56:57 1999
+++ postgresql-6.5.2-patched/src/backend/commands/command.c	Wed Mar  1 16:30:23 2000
@@ -524,7 +524,9 @@
if (lockstmt->mode == AccessShareLock)
aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), ACL_RD);
else
-		aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), ACL_WR);
+		/* do we really need to have all these permissions at the same time ? */
+		/* shouldn't we test lockstmt->mode first ? */
+		aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), (ACL_AP | ACL_DE | ACL_UP));

if (aclresult != ACLCHECK_OK)
elog(ERROR, "LOCK TABLE: permission denied");
diff -urbw postgresql-6.5.2/src/backend/commands/copy.c postgresql-6.5.2-patched/src/backend/commands/copy.c
--- postgresql-6.5.2/src/backend/commands/copy.c	Sat Jul  3 02:32:39 1999
+++ postgresql-6.5.2-patched/src/backend/commands/copy.c	Wed Mar  1 16:30:35 2000
@@ -242,7 +242,8 @@
FILE	   *fp;
Relation	rel;
extern char *UserName;		/* defined in global.c */
-	const AclMode required_access = from ? ACL_WR : ACL_RD;
+	/* why should we need other permissions than APPEND ? */
+	const AclMode required_access = from ? ACL_AP : ACL_RD;
int			result;

rel = heap_openr(relname);
diff -urbw postgresql-6.5.2/src/backend/commands/sequence.c postgresql-6.5.2-patched/src/backend/commands/sequence.c
--- postgresql-6.5.2/src/backend/commands/sequence.c	Mon Aug  2 07:56:59 1999
+++ postgresql-6.5.2-patched/src/backend/commands/sequence.c	Wed Mar  1 16:31:05 2000
@@ -314,7 +314,8 @@
Form_pg_sequence seq;

#ifndef NO_SECURITY
-	if (pg_aclcheck(seqname, getpgusername(), ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than UPDATE permission ? */
+	if (pg_aclcheck(seqname, getpgusername(), ACL_UP) != ACLCHECK_OK)
elog(ERROR, "%s.setval: you don't have permissions to set sequence %s",
seqname, seqname);
#endif
diff -urbw postgresql-6.5.2/src/backend/commands/user.c postgresql-6.5.2-patched/src/backend/commands/user.c
--- postgresql-6.5.2/src/backend/commands/user.c	Mon Aug  2 07:56:59 1999
+++ postgresql-6.5.2-patched/src/backend/commands/user.c	Wed Mar  1 16:31:38 2000
@@ -115,7 +115,7 @@
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR | ACL_AP) != ACLCHECK_OK)
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_AP | ACL_DE | ACL_UP) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "defineUser: user \"%s\" does not have SELECT and INSERT privilege for \"%s\"",
@@ -227,7 +227,8 @@
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than UPDATE ? */
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_UP) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "alterUser: user \"%s\" does not have SELECT and UPDATE privilege for \"%s\"",
@@ -329,11 +330,12 @@
BeginTransactionBlock();

/*
-	 * Make sure the user attempting to create a user can delete from the
+	 * Make sure the user attempting to delete a user can delete from the
* pg_shadow relation.
*/
pg_shadow = GetPgUserName();
-	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_WR) != ACLCHECK_OK)
+	/* why should we need more than DELETE ? */
+	if (pg_aclcheck(ShadowRelationName, pg_shadow, ACL_RD | ACL_DE) != ACLCHECK_OK)
{
UserAbortTransactionBlock();
elog(ERROR, "removeUser: user \"%s\" does not have SELECT and DELETE privilege for \"%s\"",
diff -urbw postgresql-6.5.2/src/backend/executor/execMain.c postgresql-6.5.2-patched/src/backend/executor/execMain.c
--- postgresql-6.5.2/src/backend/executor/execMain.c	Thu Jun 17 17:15:49 1999
+++ postgresql-6.5.2-patched/src/backend/executor/execMain.c	Wed Mar  1 18:31:31 2000
@@ -464,14 +464,16 @@
switch (operation)
{
case CMD_INSERT:
-					ok = ((aclcheck_result = CHECK(ACL_AP)) == ACLCHECK_OK) ||
-						((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
+					ok = ((aclcheck_result = CHECK(ACL_AP)) == ACLCHECK_OK);
opstr = "append";
break;
case CMD_DELETE:
+					ok = ((aclcheck_result = CHECK(ACL_DE)) == ACLCHECK_OK);
+					opstr = "delete";
+					break;
case CMD_UPDATE:
-					ok = ((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
-					opstr = "write";
+					ok = ((aclcheck_result = CHECK(ACL_UP)) == ACLCHECK_OK);
+					opstr = "update";
break;
default:
elog(ERROR, "ExecCheckPerms: bogus operation %d",
@@ -508,8 +510,9 @@
StrNCpy(rname.data,
((Form_pg_class) GETSTRUCT(htup))->relname.data,
NAMEDATALEN);
-			ok = ((aclcheck_result = CHECK(ACL_WR)) == ACLCHECK_OK);
-			opstr = "write";
+			/* is it the right thing to do ? */
+			ok = ((aclcheck_result = CHECK((ACL_AP | ACL_DE | ACL_UP))) == ACLCHECK_OK);
+			opstr = "write";	/* unused ? */
if (!ok)
elog(ERROR, "%s: %s", rname.data, aclcheck_error_strings[aclcheck_result]);
}
diff -urbw postgresql-6.5.2/src/backend/parser/gram.y postgresql-6.5.2-patched/src/backend/parser/gram.y
--- postgresql-6.5.2/src/backend/parser/gram.y	Tue Sep 14 08:07:35 1999
+++ postgresql-6.5.2-patched/src/backend/parser/gram.y	Wed Mar  1 16:33:34 2000
@@ -1694,11 +1694,11 @@

privileges:  ALL PRIVILEGES
{
-				 $$ = aclmakepriv("rwaR",0);
+				 $$ = aclmakepriv("raduR",0);
}
| ALL
{
-				 $$ = aclmakepriv("rwaR",0);
+				 $$ = aclmakepriv("raduR",0);
}
| operation_commalist
{
@@ -1726,11 +1726,11 @@
}
| UPDATE
{
-						$$ = ACL_MODE_WR_CHR;
+						$$ = ACL_MODE_UP_CHR;
}
| DELETE
{
-						$$ = ACL_MODE_WR_CHR;
+						$$ = ACL_MODE_DE_CHR;
}
| RULE
{
diff -urbw postgresql-6.5.2/src/backend/parser/parse.h postgresql-6.5.2-patched/src/backend/parser/parse.h
--- postgresql-6.5.2/src/backend/parser/parse.h	Thu Sep 16 02:23:39 1999
+++ postgresql-6.5.2-patched/src/backend/parser/parse.h	Wed Mar  1 18:34:46 2000
@@ -29,236 +29,236 @@
RuleStmt			*rstmt;
InsertStmt			*astmt;
} YYSTYPE;
-#define	ABSOLUTE	257
-#define	ACTION	258
-#define	ADD	259
-#define	ALL	260
-#define	ALTER	261
-#define	AND	262
-#define	ANY	263
-#define	AS	264
-#define	ASC	265
-#define	BEGIN_TRANS	266
-#define	BETWEEN	267
-#define	BOTH	268
-#define	BY	269
-#define	CASCADE	270
-#define	CASE	271
-#define	CAST	272
-#define	CHAR	273
-#define	CHARACTER	274
-#define	CHECK	275
-#define	CLOSE	276
-#define	COALESCE	277
-#define	COLLATE	278
-#define	COLUMN	279
-#define	COMMIT	280
-#define	CONSTRAINT	281
-#define	CREATE	282
-#define	CROSS	283
-#define	CURRENT	284
-#define	CURRENT_DATE	285
-#define	CURRENT_TIME	286
-#define	CURRENT_TIMESTAMP	287
-#define	CURRENT_USER	288
-#define	CURSOR	289
-#define	DAY_P	290
-#define	DECIMAL	291
-#define	DECLARE	292
-#define	DEFAULT	293
-#define	DELETE	294
-#define	DESC	295
-#define	DISTINCT	296
-#define	DOUBLE	297
-#define	DROP	298
-#define	ELSE	299
-#define	END_TRANS	300
-#define	EXCEPT	301
-#define	EXECUTE	302
-#define	EXISTS	303
-#define	EXTRACT	304
-#define	FALSE_P	305
-#define	FETCH	306
-#define	FLOAT	307
-#define	FOR	308
-#define	FOREIGN	309
-#define	FROM	310
-#define	FULL	311
-#define	GLOBAL	312
-#define	GRANT	313
-#define	GROUP	314
-#define	HAVING	315
-#define	HOUR_P	316
-#define	IN	317
-#define	INNER_P	318
-#define	INSENSITIVE	319
-#define	INSERT	320
-#define	INTERSECT	321
-#define	INTERVAL	322
-#define	INTO	323
-#define	IS	324
-#define	ISOLATION	325
-#define	JOIN	326
-#define	KEY	327
-#define	LANGUAGE	328
-#define	LEADING	329
-#define	LEFT	330
-#define	LEVEL	331
-#define	LIKE	332
-#define	LOCAL	333
-#define	MATCH	334
-#define	MINUTE_P	335
-#define	MONTH_P	336
-#define	NAMES	337
-#define	NATIONAL	338
-#define	NATURAL	339
-#define	NCHAR	340
-#define	NEXT	341
-#define	NO	342
-#define	NOT	343
-#define	NULLIF	344
-#define	NULL_P	345
-#define	NUMERIC	346
-#define	OF	347
-#define	ON	348
-#define	ONLY	349
-#define	OPTION	350
-#define	OR	351
-#define	ORDER	352
-#define	OUTER_P	353
-#define	PARTIAL	354
-#define	POSITION	355
-#define	PRECISION	356
-#define	PRIMARY	357
-#define	PRIOR	358
-#define	PRIVILEGES	359
-#define	PROCEDURE	360
-#define	PUBLIC	361
-#define	READ	362
-#define	REFERENCES	363
-#define	RELATIVE	364
-#define	REVOKE	365
-#define	RIGHT	366
-#define	ROLLBACK	367
-#define	SCROLL	368
-#define	SECOND_P	369
-#define	SELECT	370
-#define	SET	371
-#define	SUBSTRING	372
-#define	TABLE	373
-#define	TEMP	374
-#define	TEMPORARY	375
-#define	THEN	376
-#define	TIME	377
-#define	TIMESTAMP	378
-#define	TIMEZONE_HOUR	379
-#define	TIMEZONE_MINUTE	380
-#define	TO	381
-#define	TRAILING	382
-#define	TRANSACTION	383
-#define	TRIM	384
-#define	TRUE_P	385
-#define	UNION	386
-#define	UNIQUE	387
-#define	UPDATE	388
-#define	USER	389
-#define	USING	390
-#define	VALUES	391
-#define	VARCHAR	392
-#define	VARYING	393
-#define	VIEW	394
-#define	WHEN	395
-#define	WHERE	396
-#define	WITH	397
-#define	WORK	398
-#define	YEAR_P	399
-#define	ZONE	400
-#define	TRIGGER	401
-#define	COMMITTED	402
-#define	SERIALIZABLE	403
-#define	TYPE_P	404
-#define	ABORT_TRANS	405
-#define	ACCESS	406
-#define	AFTER	407
-#define	AGGREGATE	408
-#define	ANALYZE	409
-#define	BACKWARD	410
-#define	BEFORE	411
-#define	BINARY	412
-#define	CACHE	413
-#define	CLUSTER	414
-#define	COPY	415
-#define	CREATEDB	416
-#define	CREATEUSER	417
-#define	CYCLE	418
-#define	DATABASE	419
-#define	DELIMITERS	420
-#define	DO	421
-#define	EACH	422
-#define	ENCODING	423
-#define	EXCLUSIVE	424
-#define	EXPLAIN	425
-#define	EXTEND	426
-#define	FORWARD	427
-#define	FUNCTION	428
-#define	HANDLER	429
-#define	INCREMENT	430
-#define	INDEX	431
-#define	INHERITS	432
-#define	INSTEAD	433
-#define	ISNULL	434
-#define	LANCOMPILER	435
-#define	LIMIT	436
-#define	LISTEN	437
-#define	LOAD	438
-#define	LOCATION	439
-#define	LOCK_P	440
-#define	MAXVALUE	441
-#define	MINVALUE	442
-#define	MODE	443
-#define	MOVE	444
-#define	NEW	445
-#define	NOCREATEDB	446
-#define	NOCREATEUSER	447
-#define	NONE	448
-#define	NOTHING	449
-#define	NOTIFY	450
-#define	NOTNULL	451
-#define	OFFSET	452
-#define	OIDS	453
-#define	OPERATOR	454
-#define	PASSWORD	455
-#define	PROCEDURAL	456
-#define	RENAME	457
-#define	RESET	458
-#define	RETURNS	459
-#define	ROW	460
-#define	RULE	461
-#define	SEQUENCE	462
-#define	SERIAL	463
-#define	SETOF	464
-#define	SHARE	465
-#define	SHOW	466
-#define	START	467
-#define	STATEMENT	468
-#define	STDIN	469
-#define	STDOUT	470
-#define	TRUSTED	471
-#define	UNLISTEN	472
-#define	UNTIL	473
-#define	VACUUM	474
-#define	VALID	475
-#define	VERBOSE	476
-#define	VERSION	477
-#define	IDENT	478
-#define	SCONST	479
-#define	Op	480
-#define	ICONST	481
-#define	PARAM	482
-#define	FCONST	483
-#define	OP	484
-#define	UMINUS	485
-#define	TYPECAST	486
+#define	ABSOLUTE	258
+#define	ACTION	259
+#define	ADD	260
+#define	ALL	261
+#define	ALTER	262
+#define	AND	263
+#define	ANY	264
+#define	AS	265
+#define	ASC	266
+#define	BEGIN_TRANS	267
+#define	BETWEEN	268
+#define	BOTH	269
+#define	BY	270
+#define	CASCADE	271
+#define	CASE	272
+#define	CAST	273
+#define	CHAR	274
+#define	CHARACTER	275
+#define	CHECK	276
+#define	CLOSE	277
+#define	COALESCE	278
+#define	COLLATE	279
+#define	COLUMN	280
+#define	COMMIT	281
+#define	CONSTRAINT	282
+#define	CREATE	283
+#define	CROSS	284
+#define	CURRENT	285
+#define	CURRENT_DATE	286
+#define	CURRENT_TIME	287
+#define	CURRENT_TIMESTAMP	288
+#define	CURRENT_USER	289
+#define	CURSOR	290
+#define	DAY_P	291
+#define	DECIMAL	292
+#define	DECLARE	293
+#define	DEFAULT	294
+#define	DELETE	295
+#define	DESC	296
+#define	DISTINCT	297
+#define	DOUBLE	298
+#define	DROP	299
+#define	ELSE	300
+#define	END_TRANS	301
+#define	EXCEPT	302
+#define	EXECUTE	303
+#define	EXISTS	304
+#define	EXTRACT	305
+#define	FALSE_P	306
+#define	FETCH	307
+#define	FLOAT	308
+#define	FOR	309
+#define	FOREIGN	310
+#define	FROM	311
+#define	FULL	312
+#define	GLOBAL	313
+#define	GRANT	314
+#define	GROUP	315
+#define	HAVING	316
+#define	HOUR_P	317
+#define	IN	318
+#define	INNER_P	319
+#define	INSENSITIVE	320
+#define	INSERT	321
+#define	INTERSECT	322
+#define	INTERVAL	323
+#define	INTO	324
+#define	IS	325
+#define	ISOLATION	326
+#define	JOIN	327
+#define	KEY	328
+#define	LANGUAGE	329
+#define	LEADING	330
+#define	LEFT	331
+#define	LEVEL	332
+#define	LIKE	333
+#define	LOCAL	334
+#define	MATCH	335
+#define	MINUTE_P	336
+#define	MONTH_P	337
+#define	NAMES	338
+#define	NATIONAL	339
+#define	NATURAL	340
+#define	NCHAR	341
+#define	NEXT	342
+#define	NO	343
+#define	NOT	344
+#define	NULLIF	345
+#define	NULL_P	346
+#define	NUMERIC	347
+#define	OF	348
+#define	ON	349
+#define	ONLY	350
+#define	OPTION	351
+#define	OR	352
+#define	ORDER	353
+#define	OUTER_P	354
+#define	PARTIAL	355
+#define	POSITION	356
+#define	PRECISION	357
+#define	PRIMARY	358
+#define	PRIOR	359
+#define	PRIVILEGES	360
+#define	PROCEDURE	361
+#define	PUBLIC	362
+#define	READ	363
+#define	REFERENCES	364
+#define	RELATIVE	365
+#define	REVOKE	366
+#define	RIGHT	367
+#define	ROLLBACK	368
+#define	SCROLL	369
+#define	SECOND_P	370
+#define	SELECT	371
+#define	SET	372
+#define	SUBSTRING	373
+#define	TABLE	374
+#define	TEMP	375
+#define	TEMPORARY	376
+#define	THEN	377
+#define	TIME	378
+#define	TIMESTAMP	379
+#define	TIMEZONE_HOUR	380
+#define	TIMEZONE_MINUTE	381
+#define	TO	382
+#define	TRAILING	383
+#define	TRANSACTION	384
+#define	TRIM	385
+#define	TRUE_P	386
+#define	UNION	387
+#define	UNIQUE	388
+#define	UPDATE	389
+#define	USER	390
+#define	USING	391
+#define	VALUES	392
+#define	VARCHAR	393
+#define	VARYING	394
+#define	VIEW	395
+#define	WHEN	396
+#define	WHERE	397
+#define	WITH	398
+#define	WORK	399
+#define	YEAR_P	400
+#define	ZONE	401
+#define	TRIGGER	402
+#define	COMMITTED	403
+#define	SERIALIZABLE	404
+#define	TYPE_P	405
+#define	ABORT_TRANS	406
+#define	ACCESS	407
+#define	AFTER	408
+#define	AGGREGATE	409
+#define	ANALYZE	410
+#define	BACKWARD	411
+#define	BEFORE	412
+#define	BINARY	413
+#define	CACHE	414
+#define	CLUSTER	415
+#define	COPY	416
+#define	CREATEDB	417
+#define	CREATEUSER	418
+#define	CYCLE	419
+#define	DATABASE	420
+#define	DELIMITERS	421
+#define	DO	422
+#define	EACH	423
+#define	ENCODING	424
+#define	EXCLUSIVE	425
+#define	EXPLAIN	426
+#define	EXTEND	427
+#define	FORWARD	428
+#define	FUNCTION	429
+#define	HANDLER	430
+#define	INCREMENT	431
+#define	INDEX	432
+#define	INHERITS	433
+#define	INSTEAD	434
+#define	ISNULL	435
+#define	LANCOMPILER	436
+#define	LIMIT	437
+#define	LISTEN	438
+#define	LOAD	439
+#define	LOCATION	440
+#define	LOCK_P	441
+#define	MAXVALUE	442
+#define	MINVALUE	443
+#define	MODE	444
+#define	MOVE	445
+#define	NEW	446
+#define	NOCREATEDB	447
+#define	NOCREATEUSER	448
+#define	NONE	449
+#define	NOTHING	450
+#define	NOTIFY	451
+#define	NOTNULL	452
+#define	OFFSET	453
+#define	OIDS	454
+#define	OPERATOR	455
+#define	PASSWORD	456
+#define	PROCEDURAL	457
+#define	RENAME	458
+#define	RESET	459
+#define	RETURNS	460
+#define	ROW	461
+#define	RULE	462
+#define	SEQUENCE	463
+#define	SERIAL	464
+#define	SETOF	465
+#define	SHARE	466
+#define	SHOW	467
+#define	START	468
+#define	STATEMENT	469
+#define	STDIN	470
+#define	STDOUT	471
+#define	TRUSTED	472
+#define	UNLISTEN	473
+#define	UNTIL	474
+#define	VACUUM	475
+#define	VALID	476
+#define	VERBOSE	477
+#define	VERSION	478
+#define	IDENT	479
+#define	SCONST	480
+#define	Op	481
+#define	ICONST	482
+#define	PARAM	483
+#define	FCONST	484
+#define	OP	485
+#define	UMINUS	486
+#define	TYPECAST	487

extern YYSTYPE yylval;
diff -urbw postgresql-6.5.2/src/backend/parser/parse_func.c postgresql-6.5.2-patched/src/backend/parser/parse_func.c
--- postgresql-6.5.2/src/backend/parser/parse_func.c	Fri Jun 18 00:21:40 1999
+++ postgresql-6.5.2-patched/src/backend/parser/parse_func.c	Wed Mar  1 16:33:53 2000
@@ -601,7 +601,8 @@

if ((aclcheck_result = pg_aclcheck(seqrel, GetPgUserName(),
(((funcid == F_NEXTVAL) || (funcid == F_SETVAL)) ?
-						ACL_WR : ACL_RD)))
+						/* if nextval and setval are atomic, which I don't know, update should be enough */
+						ACL_UP : ACL_RD)))
!= ACLCHECK_OK)
elog(ERROR, "%s.%s: %s",
seqrel, funcname, aclcheck_error_strings[aclcheck_result]);
diff -urbw postgresql-6.5.2/src/backend/rewrite/locks.c postgresql-6.5.2-patched/src/backend/rewrite/locks.c
--- postgresql-6.5.2/src/backend/rewrite/locks.c	Sun Feb 14 00:17:44 1999
+++ postgresql-6.5.2-patched/src/backend/rewrite/locks.c	Wed Mar  1 16:34:20 2000
@@ -228,8 +228,15 @@
case CMD_INSERT:
reqperm = ACL_AP;
break;
+						case CMD_DELETE:
+							reqperm = ACL_DE;
+							break;
+						case CMD_UPDATE:
+							reqperm = ACL_UP;
+							break;
default:
-							reqperm = ACL_WR;
+							/* is it The Right Thing To Do (tm) ? */
+							reqperm = ACL_AP | ACL_DE | ACL_UP;
break;
}
else
diff -urbw postgresql-6.5.2/src/backend/rewrite/rewriteHandler.c postgresql-6.5.2-patched/src/backend/rewrite/rewriteHandler.c
--- postgresql-6.5.2/src/backend/rewrite/rewriteHandler.c	Sun Jul 11 19:54:30 1999
+++ postgresql-6.5.2-patched/src/backend/rewrite/rewriteHandler.c	Wed Mar  1 16:35:01 2000
@@ -2282,8 +2282,15 @@
case CMD_INSERT:
reqperm = ACL_AP;
break;
+				case CMD_DELETE:
+					reqperm = ACL_DE;
+					break;
+				case CMD_UPDATE:
+					reqperm = ACL_UP;
+					break;
default:
-					reqperm = ACL_WR;
+					/* is it The Right Thing To Do (tm) ? */
+					reqperm = ACL_AP | ACL_DE | ACL_UP;
break;
}

diff -urbw postgresql-6.5.2/src/backend/storage/file/fd.c postgresql-6.5.2-patched/src/backend/storage/file/fd.c
diff -urbw postgresql-6.5.2/src/backend/utils/adt/acl.c postgresql-6.5.2-patched/src/backend/utils/adt/acl.c
--- postgresql-6.5.2/src/backend/utils/adt/acl.c	Mon Aug  2 07:24:49 1999
+++ postgresql-6.5.2-patched/src/backend/utils/adt/acl.c	Wed Mar  1 16:35:53 2000
@@ -154,8 +154,11 @@
case ACL_MODE_RD_CHR:
aip->ai_mode |= ACL_RD;
break;
-			case ACL_MODE_WR_CHR:
-				aip->ai_mode |= ACL_WR;
+			case ACL_MODE_DE_CHR:
+				aip->ai_mode |= ACL_DE;
+				break;
+			case ACL_MODE_UP_CHR:
+				aip->ai_mode |= ACL_UP;
break;
case ACL_MODE_RU_CHR:
aip->ai_mode |= ACL_RU;
@@ -272,7 +275,7 @@
if (!aip)
aip = &default_aclitem;

-	p = out = palloc(strlen("group =arwR ") + 1 + NAMEDATALEN);
+	p = out = palloc(strlen("group =arRdu ") + 1 + NAMEDATALEN);
if (!out)
elog(ERROR, "aclitemout: palloc failed");
*p = '\0';
@@ -605,9 +608,8 @@
int			i;
int			l;

-	Assert(strlen(old_privlist) < 5);
-	priv = palloc(5); /* at most "rwaR" */ ;
-
+	Assert(strlen(old_privlist) < 6);
+	priv = palloc(6); /* at most "arduR" */ ;
if (old_privlist == NULL || old_privlist[0] == '\0')
{
priv[0] = new_priv;
@@ -619,7 +621,7 @@

l = strlen(old_privlist);

-	if (l == 4)
+	if (l == 5)
{							/* can't add any more privileges */
return priv;
}
diff -urbw postgresql-6.5.2/src/include/utils/acl.h postgresql-6.5.2-patched/src/include/utils/acl.h
--- postgresql-6.5.2/src/include/utils/acl.h	Fri Jul 30 19:07:22 1999
+++ postgresql-6.5.2-patched/src/include/utils/acl.h	Wed Mar  1 16:40:50 2000
@@ -54,9 +54,10 @@
#define ACL_NO			0		/* no permissions */
#define ACL_AP			(1<<0)	/* append */
#define ACL_RD			(1<<1)	/* read */
-#define ACL_WR			(1<<2)	/* write (append/delete/replace) */
-#define ACL_RU			(1<<3)	/* place rules */
-#define N_ACL_MODES		4
+#define ACL_DE			(1<<2)	/* delete */
+#define ACL_UP			(1<<3)	/* update/replace */
+#define ACL_RU			(1<<4)	/* place rules */
+#define N_ACL_MODES		5

#define ACL_MODECHG_ADD			1
#define ACL_MODECHG_DEL			2
@@ -65,7 +66,8 @@
/* change this line if you want to set the default acl permission  */
#define ACL_WORLD_DEFAULT		(ACL_NO)
/* #define		ACL_WORLD_DEFAULT		(ACL_RD|ACL_WR|ACL_AP|ACL_RU) */
-#define ACL_OWNER_DEFAULT		(ACL_RD|ACL_WR|ACL_AP|ACL_RU)
+
+#define ACL_OWNER_DEFAULT		(ACL_AP|ACL_RD|ACL_RU|ACL_DE|ACL_UP)

/*
* AclItem
@@ -118,10 +120,12 @@
#define ACL_MODECHG_ADD_CHR		'+'
#define ACL_MODECHG_DEL_CHR		'-'
#define ACL_MODECHG_EQL_CHR		'='
-#define ACL_MODE_STR			"arwR"	/* list of valid characters */
+
+#define ACL_MODE_STR			"arduR"	 /* list of valid characters */
#define ACL_MODE_AP_CHR			'a'
#define ACL_MODE_RD_CHR			'r'
-#define ACL_MODE_WR_CHR			'w'
+#define ACL_MODE_DE_CHR			'd'
+#define ACL_MODE_UP_CHR			'u'
#define ACL_MODE_RU_CHR			'R'

/* result codes for pg_aclcheck */

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026