On Wed, 14 Mar 2007, Randall Smith wrote:
> Stephan Szabo wrote:
> > On Wed, 14 Mar 2007, Randall Smith wrote:
> >
> >> Scott Marlowe wrote:
> >>> This whole discussion is reminding me of one of my personal mantras, and
> >>> that is that relying on "artifacts" of behaviour is generally a bad
> >>> idea.
> >>>
> >>> For instance, many databases accept != for not equal, but the sql
> >>> standard quite clearly says it's <>.
> >>>
> >>> If you're relying on case folding meaning that you don't have to
> >>> consistently use the same capitalization when referring to variables,
> >>> table names, people, or anything else, you're asking for trouble down
> >>> the line, and for little or no real gain today.
> >>>
> >>> I know that a lot of times we are stuck with some commercial package
> >>> that we can't do anything to fix, so I'm not aiming this comment at the
> >>> average dba, but at the developer.
> >> Yea, this is a commercial package, but it's actually doing it right.
> >> Since it doesn't know how a user will name a table or column, it always
> >> calls them as quoted strings in upper case which is standards compliant,
> >> but doesn't work with PG. So if a user names a table 55 and mine, it
> >> calls "55 AND MINE" and for foo, it calls "FOO". Looks like they did it
> >> right to me.
> >
> > Maybe, but the 55 and mine example may or may not actually work. 55 and
> > mine isn't a valid regular identifier. "55 and mine" would be a valid
> > identifier, but that's not the same identifier as "55 AND MINE".
> >
> Your right. Its not a correct example. I think the point is clear, though.
Well, I was arguing about whether the app was doing it right. Assuming
that you can uppercase and put quotes around an arbitrary table name is
wrong too, because that's only valid for regular identifiers in SQL, so I
was wondering if it had support for things that were created as quoted
identifiers (which you might be able to use as a temporary workaround).
This isn't an argument against putting spec compliant behavior into
PostgreSQL, just more of a point that getting this right through the whole
system from app to db can be somewhat tricky even in the best case.
