Re: PostgreSQL Gotchas

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Chris Travers <chris(at)travelamericas(dot)com>, Scott Marlowe <smarlowe(at)g2switchworks(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, "Aly S(dot)P Dharshi" <aly(dot)dharshi(at)telus(dot)net>, "Gavin M(dot) Roy" <gmr(at)ehpg(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: PostgreSQL Gotchas
Date: 2005-10-14 17:56:13
Message-ID: 87achcgeyq.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > So two identifiers match if either is an unquoted identifier and they match
> > case insensitively. Or if both are quoted and they match case sensitively.
>
> Which part of "adhere to the standard" are you failing to get? The
> standard is 100% clear about what it means by case folding, and the
> above is not it.

I guess I had a few unstated assumptions:

1) That we don't care what algorithm the standard specifies as long as we're
functionally equivalent.

2) That we don't care about producing errors in all the cases where following
the standard would produce an error. Ie, that as long as we accept any code
that the standard says should work we don't care if we sometimes accept
code that the standard says should produce errors like "column not found".

Also my position somewhat evolved between the beginning of the mail and the
end. Specifically I think we can aim to be compatible with specific common
standards-compliant idioms even if we don't follow the letter of the standard.

For example I think there's a ton of code out there that is nigh impossible to
port to Postgres only because it defines tables with columns like "FOO" and
then refers to them as foo or FOO. And vice versa, code that defines columns
as foo or FOO and then refers to them in queries as "FOO". There's no reason
to say it's useless to support that and make lots of code work fine under
Postgres even if that doesn't mean we fit the standard 100%.

--
greg

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2005-10-14 18:27:45 Re: [pgsql-advocacy] Oracle buys Innobase
Previous Message Joshua D. Drake 2005-10-14 17:54:24 Re: [pgsql-advocacy] Oracle buys Innobase