Re: [ADMIN] Cannot connect to the database (PG 7.3) - Mailing list pgsql-hackers

From Nigel J. Andrews
Subject Re: [ADMIN] Cannot connect to the database (PG 7.3)
Date
Msg-id Pine.LNX.4.21.0301290142170.2839-100000@ponder.fairway2k.co.uk
Whole thread Raw
In response to Re: [ADMIN] Cannot connect to the database (PG 7.3)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [ADMIN] Cannot connect to the database (PG 7.3)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 28 Jan 2003, Tom Lane wrote:

> I wrote:
> > Michiel Lange <michiel@minas.demon.nl> writes:
> >> It is, somehow, not possible to connect as a user which name is completely 
> >> numeric.
> 
> > I muttered "nonsense!" to myself, but darned if you're not right:
> 
> > regression=# create user "12345";
> > CREATE USER
> > regression=# \q
> > $ psql -U 12345 regression
> > psql: FATAL:  SET SESSION AUTHORIZATION: permission denied
> 
> > Will look into it.
> 
> After some looking, it appears the culprit is
> assign_session_authorization() in commands/variable.c, which is assuming
> that a numeric-looking parameter string should be taken as a numeric
> user sysid, rather than an actual user name.
> 
> The reason this was done was to avoid the need to do catalog lookups
> when restoring a prior setting during error recovery.  That's still a
> valid concern, so right offhand I don't see an easy fix.  Any ideas?

How about throwing an error if an all digit user name is given to create
user as already alluded to?

Seems that would be simple, not that I know anything about the parser, but does
that break any standards?


-- 
Nigel J. Andrews



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Testing for int64 (was Re: [COMMITTERS] pgsql-server/ /configure /configure.in...)
Next
From: Dave Cramer
Date:
Subject: Re: Request for qualified column names