Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> (Actually, what I'd prefer it do is try first for username, and
> >> then username@databasename if plain username isn't found.)
>
> > Yes, that would be very easy to do _except_ for pg_hba.conf which does a
> > first-match for username. We could get into trouble there by trying two
> > versions of the same name. Comments?
>
> Hm. I think we'd have to switch around the order of stuff so that we
> look at the flat-file copy of pg_shadow first. Then we'd know which
> flavor of name we have, and we can proceed with the pg_hba match.
>
> The reason it's worth doing this is that 'postgres', for example, should
> be an installation-wide username even when you're using db-local names
> for ordinary users.
Yes, that's why my code had a special case for 'postgres' or whatever
super-user name it was installed with. I think it is cleaner to just
read the install username. Also, right now, pg_pwd only contains
usernames that have passwords, not all of them.
> > This may require raising the length of NAME type to be backwards
> > compatible.
> >>
> >> Right, but we're planning to do that anyway.
>
> > Yes, but that requires a protocol change, which we don't want to do for
> > 7.3.
>
> What? We've been discussing raising NAMEDATALEN for months, and no
> one's claimed that it qualifies as a protocol version change.
I thought they were talking about increasing the length of the user NAME
that comes of the wire. That is currently 32. I see now he was just
talking about NAMEDATALEN. Good thing we are prepending the database
name after receiving the name.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
