From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Konstantin Izmailov <kizmailov(at)gmail(dot)com> |
Subject: | Re: information_schema.columns changes needed for OLEDB |
Date: | 2009-05-23 21:57:40 |
Message-ID: | 200905240057.40786.peter_e@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
From | Date | Subject | |
---|---|---|---|
Next Message | Konstantin Izmailov | 2009-05-24 00:37:28 | Re: information_schema.columns changes needed for OLEDB |
Previous Message | Peter Eisentraut | 2009-05-23 21:40:17 | Re: [PATCH] Compiler warning cleanup |