Re: [ADMIN] Cannot connect to the database (PG 7.3)
От | Tom Lane |
---|---|
Тема | Re: [ADMIN] Cannot connect to the database (PG 7.3) |
Дата | |
Msg-id | 19363.1043815258@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [ADMIN] Cannot connect to the database (PG 7.3) ("Nigel J. Andrews" <nandrews@investsystems.co.uk>) |
Список | 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 по дате отправления: