Do you mean you didn't get any output? Or you got just the numbers? If
you didn't get anything that's the old problem and I believe the same
problem holds for ODBC (Julie?). The first fetch returns no row, so the
program ends. Unfortunately I haven't changed anything I expect to be
able to cause that problem. It seems to be a backend/library problem.

Anyway, which version are you using? I cannot connect to a database
since last week or so. I tried re-initdb'ing it but get a seg fault in
the backend when doing a createuser. So my only chance of testing right
now is to manually inspect the code created.

Michael

--
Dr. Michael Meskes, Project-Manager    | topsystem Systemhaus GmbH
meskes@topsystem.de                    | Europark A2, Adenauerstr. 20
meskes@debian.org                      | 52146 Wuerselen
Go SF49ers! Go Rhein Fire!             | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!                  | Fax: (+49) 2405/4670-10

> -----Original Message-----
> From:	Keith Parks [SMTP:emkxp01@mtcc.demon.co.uk]
> Sent:	Wednesday, February 18, 1998 8:28 PM
> To:	meskes@topsystem.de
> Cc:	pgsql-hackers@postgresql.org
> Subject:	Re: New ecgp code problem.
> 
> Hi,
> 
> Things were working upto a point when I was playing yesterday.
> 
> The perftest seemed to run OK
> The test2 example ran but did not display the varchar (name) field.
> 
> I'm afraid I've not got very far debugging.
> 
> Keith.
> 
> 
> 

Thu, 19 Feb 1998 09:51:25 +0100
"Meskes, Michael" <meskes@topsystem.de>
RE: New ecgp code problem.
On Thu, 19 Feb 1998, Meskes, Michael wrote:

> Do you mean you didn't get any output? Or you got just the numbers? If
> you didn't get anything that's the old problem and I believe the same
> problem holds for ODBC (Julie?). The first fetch returns no row, so the
> program ends. Unfortunately I haven't changed anything I expect to be
> able to cause that problem. It seems to be a backend/library problem.

	I spent time with Julie last night working on this, and the
problem comes back down to "pg_user: Permission Denied"...

	I think this is a high priority problem, since it affects so many
things.

	What is the chance of (how hard would it be to?) having a hard
coded view setup that overrides the permissions lock on pg_user?  At what
point is the lock implemented, software level, or file system?

	All we would really need was:

	create view all_users as select usename,usesysid from pg_user;

	Which psql/odbc/ecgp/jdbc could call instead of what its doing
now...




Thu, 19 Feb 1998 08:02:19 -0500 (EST)
The Hermit Hacker <scrappy@hub.org>
pg_user permissions problem (Was: Re: [HACKERS] RE: New ecgp code
	problem.)
The Hermit Hacker writes:
> 	What is the chance of (how hard would it be to?) having a hard
> coded view setup that overrides the permissions lock on pg_user?  At what
> point is the lock implemented, software level, or file system?

I wasn't able to read data from a DB that I created with the very same user.
But I was able to connect, insert data etc. Why was that possible?

> 	All we would really need was:
> 
> 	create view all_users as select usename,usesysid from pg_user;
> 
> 	Which psql/odbc/ecgp/jdbc could call instead of what its doing
> now...

ecpg doesn't call anything like that. All I use is some PQ... functions. No
direct access to whatever user permission system we have. So does this have
to be changed in libpq?

Michael

-- 
Dr. Michael Meskes, Project-Manager    | topsystem Systemhaus GmbH
meskes@topsystem.de                    | Europark A2, Adenauerstr. 20
meskes@debian.org                      | 52146 Wuerselen
Go SF49ers! Go Rhein Fire!             | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!                  | Fax: (+49) 2405/4670-10

Thu, 19 Feb 1998 14:13:06 +0100 (CET)
Michael Meskes <meskes@topsystem.de>
Re: pg_user permissions problem (Was: Re: [HACKERS] RE: New ecgp code
	problem.)
> 	I spent time with Julie last night working on this, and the
> problem comes back down to "pg_user: Permission Denied"...
> 
> 	I think this is a high priority problem, since it affects so many
> things.
> 
> 	What is the chance of (how hard would it be to?) having a hard
> coded view setup that overrides the permissions lock on pg_user?  At what
> point is the lock implemented, software level, or file system?
> 

I believe the only way to fix it at this point is to remove the REVOKE
pg_user from initdb, and add a check in user.c to make sure the
permissions on pg_user are not NULL if they try and use passwords.

-- 
Bruce Momjian
maillist@candle.pha.pa.us

Thu, 19 Feb 1998 09:31:50 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: pg_user permissions problem (Was: Re: [HACKERS] RE: New ecgp code
	problem.)