Re: information_schema.columns changes needed for OLEDB - Mailing list pgsql-hackers

Number 4 is actually numeric_precision (I typed incorrectly). My recollection is that numeric_precision sometimes
expressedin radix 2 and it caused issues for Windows apps.<br /><br />I agree on other issues. I was curious if
databasecan help OLEDB driver (to make it simpler). Anyway it can emulate values for specific Windows apps on the fly.
Thankyou!<br /><br /><div class="gmail_quote">On Sat, May 23, 2009 at 2:57 PM, Peter Eisentraut <span dir="ltr"><<a
href="mailto:peter_e@gmx.net">peter_e@gmx.net</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On
Friday22 May 2009 18:27:01 Konstantin Izmailov wrote:<br /> > As we discussed at pgcon2009 there are some
changes/fixesnecessary in<br /> > information_schema.columns to allow correct work of applications and<br /> >
servicesvia OLEDB on Windows. Here are some:<br /> ><br /> > 1. data_type field contains types names that are not
recognizedby MS apps.<br /> ><br /> > Code around: rename types on the fly, e.g.<br /> ><br /> > integer
->int<br /> ><br /> > character varying -> varchar<br /> ><br /> > character -> char<br /><br
/></div>Thespelling of these types in the information schema is fixed by the SQL<br /> standard.  We can't change
that.<br/><div class="im"><br /> > timestamp without time zone -> datetime<br /><br /></div>And that would
certainlybe wrong for other applications, because PostgreSQL<br /> doesn't have a datetime type.<br /><br /> > bytea
->image<br /><br /> And that we certainly can't do either.<br /><div class="im"><br /> > 2.
character_maximum_lengthfield<br /> ><br /> > Code around: change value for text abd bytea types<br /> ><br />
>[text] 1073741823<br /><br /></div>(see next item)<br /><br /> > [bytea] 2147483647<br /><br /> But bytea is not
acharacter type in the first place, so this value is<br /> meaningless.<br /><div class="im"><br /> > 3.
character_octet_lengthshould always be double of<br /> > character_maximum_length (due to Unicode character size on
Windowswhich is<br /> > 2).<br /><br /></div>We could do something like that if we exposed the maximum octet length
ofa<br /> character per encoding.  But what I wonder is whether this should reflect the<br /> server or the client
encoding. How do your applications use this value?<br /><div class="im"><br /> > 4. datetime_precision field is not
alwayscorrect<br /> ><br /> > Code around: change value of the fly, e.g. if value is not null then<br /> ><br
/>> [numeric] keep the value (ok)<br /> ><br /> > [bigint] set value to 19<br /> ><br /> > all other set
to10<br /><br /></div>Why would numeric and bigint affect *datetime*_precision at all?<br /><div class="im"><br /> >
5.numeric_precision_radix field should always be equal to 10<br /><br /></div>Why?<br /><div class="im"><br /> > 6.
datetime_precisionfield, minor changes<br /> ><br /> > Code around: change value on the fly, e.g.<br /> ><br
/>> [date] set value to zero<br /><br /></div>Makes sense.  I think this is not correct at the moment.<br /><div
class="im"><br/> > [datetime] set value to 3<br /><br /></div>Well, it really depends on what you set it to when you
declaredthe column,<br /> no?<br /></blockquote></div><br />