On Thu, 2006-11-02 at 10:51 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > We have namespaces to differentiate between two sources of object names,
> > so anybody who creates a schema where MyColumn is not the same thing as
> > myColumn is not following sensible rules for conceptual distance.
>
> I'd agree that that is not a good design practice, but the fact remains
> that they *are* different per spec.
>
> > Would be better to make this behaviour a userset
> > switchable between the exactly compliant and the more intuitive.
>
> That's certainly not happening --- if you make any changes in the
> semantics of equality of type name, it would have to be frozen no
> later than initdb time, for exactly the same reasons we freeze
> locale then (hint: index ordering).

[Re-read all of this after Bruce's post got me thinking.]

My summary of the thread, with TODO items noted:

1. PostgreSQL doesn't follow the spec, but almost does, with regard to
comparison of unquoted and quoted identifiers. DB2 does this per spec.

2. TODO: We could follow the spec, but it would need an initdb option;
some non-SQL:2003 standard PostgreSQL programs would not work as they do
now. This is considered a minor, low priority item, though.

3. TODO: We could set column headers better if we wanted to (rather
than ?column? we could use e.g. Sum_ColumnName etc)

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Jim Nasby wrote:
> On Nov 14, 2006, at 2:42 PM, Simon Riggs wrote:
>> On Thu, 2006-11-02 at 10:51 -0500, Tom Lane wrote:
>>> "Simon Riggs" <simon@2ndquadrant.com> writes:
>>>> We have namespaces to differentiate between two sources of object
>>>> names,
>>>> so anybody who creates a schema where MyColumn is not the same
>>>> thing as
>>>> myColumn is not following sensible rules for conceptual distance.
>>>
>>> I'd agree that that is not a good design practice, but the fact remains
>>> that they *are* different per spec.
>>>
>>>> Would be better to make this behaviour a userset
>>>> switchable between the exactly compliant and the more intuitive.
>>>
>>> That's certainly not happening --- if you make any changes in the
>>> semantics of equality of type name, it would have to be frozen no
>>> later than initdb time, for exactly the same reasons we freeze
>>> locale then (hint: index ordering).
>>
>> [Re-read all of this after Bruce's post got me thinking.]
>>
>> My summary of the thread, with TODO items noted:
>>
>> 1. PostgreSQL doesn't follow the spec, but almost does, with regard to
>> comparison of unquoted and quoted identifiers. DB2 does this per spec.
>>
>> 2. TODO: We could follow the spec, but it would need an initdb option;
>> some non-SQL:2003 standard PostgreSQL programs would not work as they do
>> now. This is considered a minor, low priority item, though.
>>
>> 3. TODO: We could set column headers better if we wanted to (rather
>> than ?column? we could use e.g. Sum_ColumnName etc)
>
> Did the idea of preserving the original case and using that for output
> column names, /d, etc. get shot down? I thought it would be a useful
> addition...


I think there is broad agreement that we need to provide optional
minimally spec compliant behaviour (fold unquoted to upper case,
otherwise as now). I am not sure how invasive either the "case preserved
+ case insensitive comparison" or the "case preserved + case sensitive
comparison" option would be. I don't know that anything has been ruled
out. Until someone produces a patch or a definite design and analysis we
are a bit in the dark. Personally, I would like to see all of these as
options ;-)

I think Simon's item 3 above is a separate issue.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate