> Don't take it personally! I'm happy to accept the developers'
> decisions, since you know the code much better.
No offense taken. It's just that you got an opinion, not a "decision".
When you are bouncing ideas off of the list, you might get an opinion
back, but if you really think it should be pursued then it's OK to push
the topic to see if it resonates with someone. For something big, it
does usually take a consensus among the core developers to get it
incorporated, but on smaller issues which fit in with how things already
are it isn't that complicated.
btw, we try to not be too thin-skinned; sometimes even polite people
need to be blunt to get their point across when we're being dense :)
> >Do you really want the patch applied which disables the more
> >general user names,
> I would prefer to have Unix user names allowed throughout.
Not exactly possible with SQL92 grammar; see below...
> (What started this thread?) The problem is
> that you can't (I think) start a connection while supplying another
> user-name than your login-name, except by the -u option to psql. This
> leads to an interactive prompt for name and password.
This sounds like a feature to add to libpq and/or psql...
> >tgl=> create user "hi-there";
> >CREATE USER
> I hadn't tried double-quotes, because single-quotes are
> used for strings - it didn't occur to me! (Incidentally, WHY
> double-quotes here instead of single-quotes? Surely that's against SQL
> practice?)
I don't think so; syntactically an authorization ID seems to resemble
other identifiers, not literal strings. Identifiers are allowed to be
"delimited", when means surrounded by double-quotes, to allow mixed case
and weird characters into an identifier.
> It doesn't work for GRANT, though, with either kind of quote:
Yeah, well, that is probably a smaller problem. Perhaps there is a query
buried in the backend which needs to have some double-quoting applied.
We can look into it, eh?
> Overall, it seems to me that a user-name is just a string, that is
> used as a key into pg_shadow. The SQL92 definition allows it to be a
> character string literal.
I don't see this in my reference books. A character string literal is
delimited by single-quotes; never run across it for a user name
(actually an "authorization ID" in SQL92).
> So there ought to be no problem in specifying
> a string rather than an identifier in all the relevant places.
> (I speak in happy ignorance of whatever the real problems may be!)
Yup :)
The SQL92 character set specifically allows only a few characters other
than [A-Za-z0-9] in non-delimited identifiers. And, it specifically
defines most other interesting characters (including "-") as explicit
delimiters.
I think we should concentrate on making the features work as well as
possible within the SQL92 framework, and within the limitations of our
lex/yacc grammar.
Delimited identifiers are afaik the way to do this...
- Tom
