Re: [SQL] Case Preservation disregarding case
От | Andrew Dunstan |
---|---|
Тема | Re: [SQL] Case Preservation disregarding case |
Дата | |
Msg-id | 455B5537.3060905@dunslane.net обсуждение исходный текст |
Ответ на | Re: [SQL] Case Preservation disregarding case (Jim Nasby <jim@nasby.net>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: