Re: [SQL] Case Preservation disregarding case

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: [SQL] Case Preservation disregarding case
Дата
Msg-id E019F6B3-0E16-4FE8-9787-14250841C3D1@nasby.net
обсуждение исходный текст
Ответ на Re: [SQL] Case Preservation disregarding case  ("Simon Riggs" <simon@2ndquadrant.com>)
Ответы Re: [SQL] Case Preservation disregarding case  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
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...
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)






В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mario Guenterberg
Дата:
Сообщение: subscribe
Следующее
От: Oleg Bartunov
Дата:
Сообщение: building postgresql documentation