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
|
Список | 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 по дате отправления: