From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk> |
Cc: | Michiel Lange <michiel(at)minas(dot)demon(dot)nl>, pgsql-hackers(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Subject: | Re: [ADMIN] Cannot connect to the database (PG 7.3) |
Date: | 2003-01-29 04:40:58 |
Message-ID: | 19363.1043815258@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin 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
From | Date | Subject | |
---|---|---|---|
Next Message | Yudha Setiawan | 2003-01-29 04:50:40 | Error Code |
Previous Message | Tom Lane | 2003-01-29 02:00:52 | Re: [ADMIN] Cannot connect to the database (PG 7.3) |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-01-29 05:34:19 | Upcoming events |
Previous Message | Rod Taylor | 2003-01-29 04:39:50 | Strange Prepare bug |