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

From Tom Lane
Subject Re: [ADMIN] Cannot connect to the database (PG 7.3)
Date
Msg-id 19363.1043815258@sss.pgh.pa.us
Whole thread Raw
In response to Re: [ADMIN] Cannot connect to the database (PG 7.3)  ("Nigel J. Andrews" <nandrews@investsystems.co.uk>)
List pgsql-hackers
>> 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?

I've got an idea ... it's a bit grotty, but certainly not as ugly as
prohibiting all-numeric user names.

The problem for assign_session_authorization is to store a numeric sysid
in a form that can't be mistaken for a user name.  There is no string
that can't be generated by a quoted identifier (except for strings with
embedded nulls, which won't really help us here).  However, there *is*
the NAMEDATALEN limit.  What if we generate strings consisting of, say,
NAMEDATALEN+1 'x's and then the numeric sysid?

This might seem a tad wasteful of storage, but at most a couple of such
strings need be stored at one time, so it's really insignificant (the
code space to implement any more-complex solution would probably be
more).

If anyone has a cleaner solution, let's hear it; otherwise I'll put this
in.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: Strange Prepare bug
Next
From: "Ross J. Reedstrom"
Date:
Subject: Re: Can we revisit the thought of PostgreSQL 7.2.4?