On Monday 06 July 2009 22:16:12 Tom Lane wrote:
> Peter Eisentraut writes:
> > I have the attached patch that would make character_octet_length the
> > product of character_octet_length and the maximum octet length of a
> > single character in the selected server encoding. So for UTF-8, this
> >
Peter Eisentraut writes:
> I have the attached patch that would make character_octet_length the product
> of character_octet_length and the maximum octet length of a single character
> in the selected server encoding. So for UTF-8, this would be factor 4. This
> doesn't exactly correspond to t
On Friday 22 May 2009 18:27:01 Konstantin Izmailov wrote:
> 3. character_octet_length should always be double of
> character_maximum_length (due to Unicode character size on Windows which is
> 2).
I have the attached patch that would make character_octet_length the product
of character_octet_leng
Peter Eisentraut writes:
> After gathering that there will probably be some other changes before
> release that will require an initdb (even without catversion bump), and
> after reexamining the issue, I think it's trivial and uncontroversial to
> fix the datetime issues:
For the benefit of anyon
Peter Eisentraut writes:
> diff --git a/src/backend/catalog/information_schema.sql
> b/src/backend/catalog/information_schema.sql
> index 9c5672f..cb0296a 100644
> --- a/src/backend/catalog/information_schema.sql
> +++ b/src/backend/catalog/information_schema.sql
> @@ -160,12 +160,12 @@ CREATE FU
On Monday 08 June 2009 07:12:33 Tom Lane wrote:
> Peter Eisentraut writes:
> > On Sunday 31 May 2009 18:41:55 Tom Lane wrote:
> >> AFAICS, the SQL standard demands that precision and scale fields be
> >> non-null all the time for those data types where they make sense
> >> (this is encoded in the
Peter Eisentraut writes:
> On Sunday 31 May 2009 18:41:55 Tom Lane wrote:
>> AFAICS, the SQL standard demands that precision and scale fields be
>> non-null all the time for those data types where they make sense
>> (this is encoded in the CHECK CONSTRAINTs that are declared for the
>> various inf
On Sunday 31 May 2009 18:41:55 Tom Lane wrote:
> AFAICS, the SQL standard demands that precision and scale fields be
> non-null all the time for those data types where they make sense
> (this is encoded in the CHECK CONSTRAINTs that are declared for the
> various information-schema tables, see part
Robert Haas writes:
> Is this a regression relative to 8.3? If not, why not leave it for
> 8.5?
No. it's not a regression. What I was concerned about was mainly that
it seemed likely to drop off the radar screen without being addressed at
all, since most of the other things Konstantin complaine
On Sun, May 31, 2009 at 11:41 AM, Tom Lane wrote:
> I'd prefer to avoid a catversion bump at this stage of the cycle,
> but it looks like any changes here would merely involve the bodies of
> some functions in information_schema.sql. I think we could just change
> them without a catversion bump.
Peter Eisentraut writes:
> On Friday 22 May 2009 18:27:01 Konstantin Izmailov wrote:
>> [ discussion of some details of information_schema results ]
Are we going to do anything about any of these issues?
In particular,
>> 6. datetime_precision field, minor changes
>>
>> Code around: change valu
Tom,
this is very helpful - thank you so much!
I had to discover those 'missing' functions one by one, usually after users'
complaints.
Konstantin
On Fri, May 29, 2009 at 11:35 AM, Tom Lane wrote:
> Konstantin Izmailov writes:
> > you know that some Postgres functions are listed in pg_proc wh
Konstantin Izmailov writes:
> you know that some Postgres functions are listed in pg_proc while others are
> not. For example, all Data Type Formatting function are in pg_proc (to_char,
> to_hex, ...). While several of the Date/Time Functions are not there
> (extract, localtime, ...).
The ones th
Hi,
I'm not sure that it is related to information_schema but I wanted to let
you know that some Postgres functions are listed in pg_proc while others are
not. For example, all Data Type Formatting function are in pg_proc (to_char,
to_hex, ...). While several of the Date/Time Functions are not ther
On Sunday 24 May 2009 03:37:28 Konstantin Izmailov wrote:
> 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.
It is measured in radix 2 for floating-point types and in ra
Josh Berkus wrote:
On 5/23/09 7:37 PM, Konstantin Izmailov wrote:
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
On 5/23/09 7:37 PM, Konstantin Izmailov wrote:
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
(t
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
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
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 fl
20 matches
Mail list logo
