On Monday 06 July 2009 22:16:12 Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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,
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_length
Peter Eisentraut pete...@gmx.net 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
On Monday 08 June 2009 07:12:33 Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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 @@
Peter Eisentraut pete...@gmx.net 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
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
Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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:
On Sun, May 31, 2009 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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
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
Konstantin Izmailov pgf...@gmail.com 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, ...).
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 t...@sss.pgh.pa.us wrote:
Konstantin Izmailov pgf...@gmail.com writes:
you know that some Postgres
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
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 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
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 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
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
20 matches
Mail list logo
