Number 4 is actually numeric_precision (I typed incorrectly). My recollection is that numeric_precision sometimes expressed in radix 2 and it caused issues for Windows apps.
I agree on other issues. I was curious if database can help OLEDB driver (to make it simpler). Anyway it can emulate values for specific Windows apps on the fly. Thank you! On Sat, May 23, 2009 at 2:57 PM, Peter Eisentraut <pete...@gmx.net> wrote: > On Friday 22 May 2009 18:27:01 Konstantin Izmailov wrote: > > As we discussed at pgcon2009 there are some changes/fixes necessary in > > information_schema.columns to allow correct work of applications and > > services via OLEDB on Windows. Here are some: > > > > 1. data_type field contains types names that are not recognized by MS > apps. > > > > Code around: rename types on the fly, e.g. > > > > integer -> int > > > > character varying -> varchar > > > > character -> char > > The spelling of these types in the information schema is fixed by the SQL > standard. We can't change that. > > > timestamp without time zone -> datetime > > And that would certainly be wrong for other applications, because > PostgreSQL > doesn't have a datetime type. > > > bytea -> image > > And that we certainly can't do either. > > > 2. character_maximum_length field > > > > Code around: change value for text abd bytea types > > > > [text] 1073741823 > > (see next item) > > > [bytea] 2147483647 > > But bytea is not a character type in the first place, so this value is > meaningless. > > > 3. character_octet_length should always be double of > > character_maximum_length (due to Unicode character size on Windows which > is > > 2). > > We could do something like that if we exposed the maximum octet length of a > character per encoding. But what I wonder is whether this should reflect > the > server or the client encoding. How do your applications use this value? > > > 4. datetime_precision field is not always correct > > > > Code around: change value of the fly, e.g. if value is not null then > > > > [numeric] keep the value (ok) > > > > [bigint] set value to 19 > > > > all other set to 10 > > Why would numeric and bigint affect *datetime*_precision at all? > > > 5. numeric_precision_radix field should always be equal to 10 > > Why? > > > 6. datetime_precision field, minor changes > > > > Code around: change value on the fly, e.g. > > > > [date] set value to zero > > Makes sense. I think this is not correct at the moment. > > > [datetime] set value to 3 > > Well, it really depends on what you set it to when you declared the column, > no? >
