> > > Some mentioned using user@dbname, though the idea of sorting made
> > > several recant their votes.
> > >
> > > So, based on the voting, I think dbname.username is an agreed-upon
> > > feature addition for 7.3. I will work on a final patch with
> > > documentation and post it to the patches list for more comment.
> >
> > The nice thing about using an @ sign, amongst being more consistent
> > with kerberos and email, is that it doesn't preclude the use of .'s in
> > a database name. For simplicity's sake, I'd really like to be able to
> > continue issuing database names that are identical to the domain that
> > they serve and worry that relying on a "." will either make the use of
> > a dot in the username or database impossible. An @ sign, on the other
> > hand, is the ubiquitously agreed upon username/host separator and
> > makes it all that much more consistent for users and administrators.
> >
> > Username: john.doe
> > Database: foo.com
> > possible pg_shadow entry #1: john.doe.foo.com
> > possible pg_shadow entry #2: john.doe@foo.com
> >
> > If people are worried about the sorting, ORDER BY domain, username.
> > My $0.02. -sc
>
> Well, they aren't separate fields so you can't ORDER BY domain. The dot
> was used so it looks like a schema based on dbname.
Sorry, I know it's a single field and that there is no split()
function (that I'm aware of), but that seems like such a small and
easy to fix problem that I personally place a higher value on the more
standard nomeclature and use of an @ sign. I understand the value of
. for schemas and whatnot, but isn't a user going to be in their own
schema to begin with? As for the order by, I've got a list of users
per "account" (sales account), so doing the order by is on two columns
and the pg_shadow table is generated periodically from our inhouse
tables. -sc
--
Sean Chittenden
