Re: [BUGS] BUG #4294: XML support: name() xpath function not working

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is there any TODO here?
> 
> It's clearly broken, if that's what you mean.  I don't know enough XPath
> to speculate about an appropriate fix.

The XML wiki already had bug reports about  so I added this report to
that list.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #4294: XML support: name() xpath function not working

[Tom Lane]

Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is there any TODO here?

It's clearly broken, if that's what you mean.  I don't know enough XPath
to speculate about an appropriate fix.

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #4294: XML support: name() xpath function not working

[Bruce Momjian]

Is there any TODO here?

---

Tom Lane wrote:
> "Enrico Sirola" <[EMAIL PROTECTED]> writes:
> > -- bad
> > select xpath('name(/my:a/*[last()])', test, ARRAY[ARRAY['my',
> > 'http://myns.com/ns']]) from test;
> 
> You could barely swat a fly with what I know about XPath ... but I'm
> thinking that the culprit here is the crock at lines 3254-3288 of
> xml.c, which explains itself thus:
> 
> /*
>  * To handle both documents and fragments, regardless of the fact whether
>  * the XML datum has a single root (XML well-formedness), we wrap the XML
>  * datum in a dummy element (...) and extend the XPath expression
>  * accordingly.  To do it, throw away the XML prolog, if any.
>  */
> 
> This code prefixes the given path expression with "/x", which of course
> is going to break any expression that starts with a function name.  It
> would have to stick the /x inside the function argument to have any
> chance of working.  In general, I think this has zero chance of working
> without implementing a pretty complete XPath parser.  We need to find
> another way.
> 
>   regards, tom lane
> 
> -- 
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #4281: some types of errors do not log statements

[Tom Lane]

Bruce Momjian <[EMAIL PROTECTED]> writes:
> thomas wrote:
>> 2008-07-05 02:16:15 CEST 6644 486ebab4.19f4 127.0.0.1(1616)ERROR:  invalid
>> byte sequence for encoding "UTF8": 0xc474

> I am unclear what would cause this.

An encoding violation in an incoming SQL command would cause it, because
we won't have set debug_query_string yet.  And there is no easy fix for
that, because we certainly don't want to have illegally encoded data
inside the backend.  The best possible scenario would be that you get
a different error while trying to translate the string back out for the
client, and the worst would be one of those recursive encoding-error-
during-error-reporting crashes.

I think the short answer is that the OP needs to fix his client code to
not generate queries that are illegally encoded according to what he has
set client_encoding to be.

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] FAQ 1.1 has wrong developer's FAQ address

[Bruce Momjian]

Alvaro Herrera wrote:
> Hi,
> 
> It says here http://www.postgresql.org/docs/faqs.FAQ.html that the
> developer's FAQ is at http://www.postgresql.org/docs/faqs.FAQ_DEV.html
> which is very outdated.  The new location is
> http://wiki.postgresql.org/wiki/Developer_FAQ

Fixed, but I think we need to move the main FAQ to a wiki at some
point.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] FAQ 1.1 has wrong developer's FAQ address

[Alvaro Herrera]

Hi,

It says here http://www.postgresql.org/docs/faqs.FAQ.html that the
developer's FAQ is at http://www.postgresql.org/docs/faqs.FAQ_DEV.html
which is very outdated.  The new location is
http://wiki.postgresql.org/wiki/Developer_FAQ

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #4370: connectby method

[Euler Taveira de Oliveira]

Derek & Bob escreveu:
> I've got a question about table connectby method. Say, we have five elements
> which are 1,2,3,4,5. Each of them are the roots in the tree.Instead of using
> five connectby methods to generate them all in the table, I assume there is
> a element 0, which is the parent of them, in the tree(which is not existed
> in the real table). So only one  connectby is enough to get them all, and it
> works. 
> 
This is *not* a bug. How would connectby guess you want to group all of
the root elements? Maybe another connectby variant that assumes
start_with as an array. A patch would be welcome.


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #4274: uuid returns duplicate values

[Eric P. Melbardis]

Hi

I downloaded the latest version from the specified url.
Put dll in the postgres "C:\Program Files\PostgreSQL\8.3\lib" directory, and 
restarted postgres service


Sorry, still does not work!

nkworks3=# SELECT test_uuid(10);
INFO:  uuid = a1942895-bdb4-484a-a3fd-6b90e7652d8c
INFO:  uuid = f2b4a00f-52a0-4a63-aac0-0500b9e6d438
INFO:  uuid = f2b4a00f-52a0-4a63-aac0-0500b9e6d438
INFO:  uuid = c6607966-0685-4d09-87f5-c593f3dd8924
INFO:  uuid = b52c719e-6484-49e6-87db-d885d45d7313
INFO:  uuid = b52c719e-6484-49e6-87db-d885d45d7313
INFO:  uuid = b52c719e-6484-49e6-87db-d885d45d7313
INFO:  uuid = b52c719e-6484-49e6-87db-d885d45d7313
INFO:  uuid = b52c719e-6484-49e6-87db-d885d45d7313
INFO:  uuid = b52c719e-6484-49e6-87db-d885d45d7313
 test_uuid
---

(1 row)

Regards

Eric


-Original Message-
From: Hiroshi Saito [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2008 8:03 PM
To: Bruce Momjian
Cc: Eric P. Melbardis; Nicolas ANTONINI; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #4274: uuid returns duplicate values

Hi.

Yes, Finally Ralf-san adjusts this patch.
http://winpg.jp/~saito/pg_work/OSSP_win32/.
Therefore, it is contained in the next release.(1.6.3/4)

Thanks!!

Regards,
Hiroshi Saito

- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>


> Hiroshi Saito wrote:
>> Hi.
>>
>> This can obtain a comfortable result.
>> http://winpg.jp/~saito/pg_work/OSSP_win32/pg8.3.3-win-bin-uuid-ossp-20080706.zip
>>
>> I will adjust with Rarf-san.
>
> Has this been completed?
>
> --
>  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
>  EnterpriseDB http://enterprisedb.com
>
>  + If your life is a hard drive, Christ can be your backup. +
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #4281: some types of errors do not log statements

[Bruce Momjian]

thomas wrote:
> 
> The following bug has been logged online:
> 
> Bug reference:  4281
> Logged by:  thomas
> Email address:  [EMAIL PROTECTED]
> PostgreSQL version: 8.3.3
> Operating system:   Windows 2003
> Description:some types of errors do not log statements
> Details: 
> 
> this isn't really a bug but rather a request for an improvement.
> 
> i've noticed that in some cases of errornous sql statements, the statement
> itself is logged to the pg_log, in other cases it isn't:
> 
> logged:
> 
> 2008-07-05 01:53:02 CEST 3528 486eade5.dc8 10.1.1.71(53082)ERROR:  column
> "xyz" does not exist at character 294
> 2008-07-05 01:53:02 CEST 3528 486eade5.dc8 10.1.1.71(53082)STATEMENT: 
> SELECT xyz FROM test
> 
> 
> not logged:
> 
> 2008-07-05 02:16:15 CEST 6644 486ebab4.19f4 127.0.0.1(1616)ERROR:  invalid
> byte sequence for encoding "UTF8": 0xc474
> 2008-07-05 02:16:15 CEST 6644 486ebab4.19f4 127.0.0.1(1616)HINT:  This error
> can also happen if the byte sequence does not match the encoding expected by
> the server, which is controlled by "client_encoding".
> 
> 
> it would be usefull to always see the sql statement that provoked the error.
> especially in the case of wrong utf byte sequences it can get very difficult
> to find the point of failure without more information. 

I am unclear what would cause this.  Is the STATEMENT: line coming from
log_statement?  What is the query that is not showing?

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #4274: uuid returns duplicate values

[Bruce Momjian]

Hiroshi Saito wrote:
> Hi.
> 
> Yes, Finally Ralf-san adjusts this patch. 
> http://winpg.jp/~saito/pg_work/OSSP_win32/.
> Therefore, it is contained in the next release.(1.6.3/4)

OK, good.  Does any of this get applied to contrib/uuid-ossp?

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #4372: TO_DATE with ISO week and day

[Bruce Momjian]

Kees Westerlaken wrote:
> 
> The following bug has been logged online:
> 
> Bug reference:  4372
> Logged by:  Kees Westerlaken
> Email address:  [EMAIL PROTECTED]
> PostgreSQL version: 8.3.3
> Operating system:   Windows
> Description:TO_DATE with ISO week and day
> Details: 
> 
> The TO_DATE conversion with ISO week (IW) and ISO day (ID) format accepts
> invalid values and sometimes returns wrong result.
> 
> select to_date('2008-31-4','IYYY-IW-ID')
> results in "2008-07-31", which is correct
> 
> The valid values for IW are 1-7, however:

I think you mean "valid values for ID".

> select to_date('2008-31-8','IYYY-IW-ID')
> results in "2008-08-04" of which you could argue if it is correct.

It is true we don't error out as often as Oracle for to_date().  We have
a TODO item for this:

Fix to_date()-related functions to consistently issue errors

* Invalid to_date patterns (was: [PATCHES] [GENERAL] ISO week 
dates) 

> However:
> select to_date('2008-31-10','IYYY-IW-ID')
> results in "2008-07-28", which is not correct

Well, as you said ID=10 isn't a valid value, so the code defaults to
Monday, but it seems it goes to the next week until Tuesday, then wraps
back, which is odd.

> And even worse: if you use the IW and ID format in an older version it
> works, but the result is wrong.
> select to_date('2008-31-4','IYYY-IW-ID')
> in version 8.2.6 results in "2004-07-26", which is wrong.

Yes, we have fixed some of this in 8.3.

I have added your report to the existing TODO item.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] range value problem with double precision [PG 8.3.3]

[Tom Lane]

Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The following, however, appears to be a bug:

> peter=# select '1E-324'::float8;
> ERROR:  22P02: invalid input syntax for type double precision: "1E-324"
> LOCATION:  float8in, float.c:431

I see this behavior on Fedora 9, but not on HPUX.  Investigation shows
that F9's strtod returns EDOM not ERANGE for this case.  Seems like a
glibc bug ...

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #4371: Foreign Key constraints not working with ODBC

[Hiroshi Saito]

Hi.

Ahh ...Probably, It will solve by the next release.
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/docs/release.html.diff?r1=1.37&r2=1.38
4.) Change the implemetatin of SQLForeignKeys() for 8.3+ servers.
It is still under adjustment with a check now. and a little patch are due to be 
added.
If possible. please try CVS-HEAD.

Regards,
Hiroshi Saito

- Original Message - 
From: "Zahid Khan" <[EMAIL PROTECTED]>





The following bug has been logged online:

Bug reference:  4371
Logged by:  Zahid Khan
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system:   Linux
Description:Foreign Key constraints not working with ODBC
Details:

I am unable to get the foreign key information using SQLForeignKeys() API
function of psqlODBC driver. Same driver works with PG8.2 and returns
success on SQLFetch() with SQLForeignKeys() call. But in PG8.3 i am getting
NO_DATA_FOUND on SQLFetch() call.

Please find below sample code how i am using this.

 cliRC = SQLForeignKeys(hstmt, NULL, 0, tbSchema, SQL_NTS, tbName, SQL_NTS,
NULL, 0, NULL, SQL_NTS, NULL, SQL_NTS);

/* bind column 6 to variable */
 cliRC = SQLBindCol(hstmt, 6, SQL_C_CHAR, (SQLPOINTER)fkTableSch.val, 129,
&fkTableSch.ind);

 /* bind column 7 to variable */
 cliRC = SQLBindCol(hstmt, 7, SQL_C_CHAR, (SQLPOINTER)fkTableName.val, 129,
&fkTableName.ind);

 /* bind column 8 to variable */
 cliRC = SQLBindCol(hstmt, 8, SQL_C_CHAR, (SQLPOINTER)fkColumnName.val,
129, &fkColumnName.ind);

 /* fetch each row and display */
 WriteResultFile( "\nFetch each row and display.\n");

 /* fetch next row */
 cliRC = SQLFetch(hstmt);

 if (cliRC == SQL_NO_DATA_FOUND)
 {
   WriteResultFile( "\nData not found.\n");
 }


 As a reference following are the quires which odbc driver is sending to
server for getting this information.

Query is [SELECTpt.tgargs,  pt.tgnargs, pt.tgdeferrable,
 pt.tginitdeferred,   pp1.proname,pp2.proname,pc.oid,
pc1.oid,pc1.relname,pt.tgconstrname, pn1.nspname FROM
pg_catalog.pg_class pc, pg_catalog.pg_class pc1,
pg_catalog.pg_proc pp,  pg_catalog.pg_proc pp1, pg_catalog.pg_proc
pp2, pg_catalog.pg_trigger pt,   pg_catalog.pg_trigger pt1,
pg_catalog.pg_trigger pt2,  pg_catalog.pg_namespace pn,
pg_catalog.pg_namespace pn1 WHERE  pc.relname='DEPT321'AND pn.nspname =
'public'AND pc.relnamespace = pn.oidAND pt.tgconstrrelid =
pc.oid   AND pp.oid = pt.tgfoid  AND pp.proname Like '%ins'  AND
pt1.tgconstrname = pt.tgconstrname  AND pt1.tgconstrrelid = pt.tgrelid
AND pt1.tgrelid = pc.oidAND pc1.oid = pt.tgrelidAND pp1.oid
= pt1.tgfoidAND pp1.proname like '%upd' AND (pp1.proname not
like '%check%')   AND pt2.tgconstrname = pt.tgconstrname   AND
pt2.tgconstrrelid = pt.tgrelid AND pt2.tgrelid = pc.oid AND
pp2.oid = pt2.tgfoidAND pp2.proname Like '%del' AND pn1.oid =
pc1.relnamespace  order by pt.tgconstrname]

***
Query is [select ta.attname, ia.attnum, ic.relname, n.nspname, tc.relname
from pg_catalog.pg_attribute ta, pg_catalog.pg_attribute ia,
pg_catalog.pg_class tc, pg_catalog.pg_index i, pg_catalog.pg_namespace n,
pg_catalog.pg_class ic where tc.relname = 'dept321' AND n.nspname = 'public'
AND tc.oid = i.indrelid AND n.oid = tc.relnamespace AND i.indisprimary = 't'
AND ia.attrelid = i.indexrelid AND ta.attrelid = i.indrelid AND ta.attnum =
i.indkey[ia.attnum-1] AND (NOT ta.attisdropped) AND (NOT ia.attisdropped)
AND ic.oid = i.indexrelid order by ia.attnum]

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs 



--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] range value problem with double precision [PG 8.3.3]

[Zahid Khan]

hmmm,What I see is, I was getting error  of underflow valuein PG8.2  when i 
tried to insert '1E-307' in table with double precision.And my application was 
expecting the same error condition with the same values  against PG 8.3.3 as 
well.but now thats not the case?

Thanks,
Zahid K.

--- On Fri, 8/22/08, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
From: Peter Eisentraut <[EMAIL PROTECTED]>
Subject: Re: [BUGS] range value problem with double precision [PG 8.3.3]
To: pgsql-bugs@postgresql.org, [EMAIL PROTECTED]
Date: Friday, August 22, 2008, 5:43 AM

Zahid Khan wrote:
> Hi ,
>
>  I see one issue pg 8.3.3 .
>
> 1.
> According to the documentation of pg "The double precision type
> typically has a range of around 1E-307 to 1E+308 with a precision of at
> least 15 digits".
>
> ref:-
>  http://www.postgresql.org/docs/8.3/static/datatype-numeric.html
>
> but in PG8.3 the values less then minimum range are being inserted.
>
> e.g
> . on insertion of 1E-308 we should get an error of "out of range or
> underflow value" but this value is being accepted by server.

The operating words are "typically" and "around".  You can
put in smaller and 
larger values, but then the precision is going to degrade, as you can observe 
here:

peter=# select '1E-305'::float8;
 float8

 1e-305
(1 row)

peter=# select '1E-310'::float8;
float8
---
 9.97e-311
(1 row)

peter=# select '1E-315'::float8;
float8
---
 9.9998481684e-316
(1 row)

peter=# select '1E-320'::float8;
float8
---
 9.99988867182683e-321
(1 row)

peter=# select '1E-325'::float8;
ERROR:  22003: "1E-325" is out of range for type double precision
LOCATION:  float8in, float.c:426

The following, however, appears to be a bug:

peter=# select '1E-324'::float8;
ERROR:  22P02: invalid input syntax for type double precision:
"1E-324"
LOCATION:  float8in, float.c:431



  

[BUGS] Installation Problems

[Bernard Stewe]

Hi 

We are trying to install postgres 8.3.0 on solaris 9.

The installation process comes up with the following error.

Please mail [EMAIL PROTECTED] as I will be out of the office for a month

 

bash-2.05$ ldd initdb

libxslt.so.1 =>  /lib/libxslt.so.1

libxml2.so.2 =>  /lib/libxml2.so.2

libpam.so.1 =>   /lib/libpam.so.1

libssl.so.0.9.8 =>   /usr/local/ssl/lib/libssl.so.0.9.8

libcrypto.so.0.9.8 =>/usr/local/ssl/lib/libcrypto.so.0.9.8

libkrb5.so.1 =>  (file not found)

libz.so.1 => /lib/libz.so.1

libcurses.so.1 =>/lib/libcurses.so.1

libsocket.so.1 =>/lib/libsocket.so.1

libm.so.2 => /lib/libm.so.2

libc.so.1 => /lib/libc.so.1

libc.so.1 (SUNW_1.22) => (version not found)

libpthread.so.1 =>   /lib/libpthread.so.1

libm.so.1 => /lib/libm.so.1

libnsl.so.1 =>   /lib/libnsl.so.1

libdl.so.1 =>/lib/libdl.so.1

libcmd.so.1 =>   /lib/libcmd.so.1

libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1

libmp.so.2 =>/lib/libmp.so.2

/usr/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1

libthread.so.1 =>/lib/libthread.so.1

 

 

Regards

 

Bernard Stewe
System Administrator: UNIX

4CIT Software Solutions   

Tel:   +27(0)21 979 0900 ext. 200

Fax:  +27(0)21 979 0902

Cell:  +27(0)79 885 6809

 

[BUGS] BUG #4372: TO_DATE with ISO week and day

[Kees Westerlaken]

The following bug has been logged online:

Bug reference:  4372
Logged by:  Kees Westerlaken
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system:   Windows
Description:TO_DATE with ISO week and day
Details: 

The TO_DATE conversion with ISO week (IW) and ISO day (ID) format accepts
invalid values and sometimes returns wrong result.

select to_date('2008-31-4','IYYY-IW-ID')
results in "2008-07-31", which is correct

The valid values for IW are 1-7, however:
select to_date('2008-31-8','IYYY-IW-ID')
results in "2008-08-04" of which you could argue if it is correct.

However:
select to_date('2008-31-10','IYYY-IW-ID')
results in "2008-07-28", which is not correct

And even worse: if you use the IW and ID format in an older version it
works, but the result is wrong.
select to_date('2008-31-4','IYYY-IW-ID')
in version 8.2.6 results in "2004-07-26", which is wrong.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] range value problem with double precision [PG 8.3.3]

[Peter Eisentraut]

Zahid Khan wrote:
> Hi ,
>
>  I see one issue pg 8.3.3 .
>
> 1.
> According to the documentation of pg "The double precision type
> typically has a range of around 1E-307 to 1E+308 with a precision of at
> least 15 digits".
>
> ref:-
>  http://www.postgresql.org/docs/8.3/static/datatype-numeric.html
>
> but in PG8.3 the values less then minimum range are being inserted.
>
> e.g
> . on insertion of 1E-308 we should get an error of "out of range or
> underflow value" but this value is being accepted by server.

The operating words are "typically" and "around".  You can put in smaller and 
larger values, but then the precision is going to degrade, as you can observe 
here:

peter=# select '1E-305'::float8;
 float8

 1e-305
(1 row)

peter=# select '1E-310'::float8;
float8
---
 9.97e-311
(1 row)

peter=# select '1E-315'::float8;
float8
---
 9.9998481684e-316
(1 row)

peter=# select '1E-320'::float8;
float8
---
 9.99988867182683e-321
(1 row)

peter=# select '1E-325'::float8;
ERROR:  22003: "1E-325" is out of range for type double precision
LOCATION:  float8in, float.c:426

The following, however, appears to be a bug:

peter=# select '1E-324'::float8;
ERROR:  22P02: invalid input syntax for type double precision: "1E-324"
LOCATION:  float8in, float.c:431

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] range value problem with double precision [PG 8.3.3]

[Zahid Khan]

Hi ,

 I see one issue pg 8.3.3 .

1.
According to the documentation of pg "The double precision type
typically has a range of around 1E-307 to 1E+308 with a precision of at
least 15 digits".

ref:-
 http://www.postgresql.org/docs/8.3/static/datatype-numeric.html

but in PG8.3 the values less then minimum range are being inserted.

e.g
. on insertion of 1E-308 we should get an error of "out of range or
underflow value" but this value is being accepted by server.



Thanks,
Zahid K.



  

[BUGS] BUG #4371: Foreign Key constraints not working with ODBC

[Zahid Khan]

The following bug has been logged online:

Bug reference:  4371
Logged by:  Zahid Khan
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system:   Linux
Description:Foreign Key constraints not working with ODBC
Details: 

I am unable to get the foreign key information using SQLForeignKeys() API
function of psqlODBC driver. Same driver works with PG8.2 and returns
success on SQLFetch() with SQLForeignKeys() call. But in PG8.3 i am getting
NO_DATA_FOUND on SQLFetch() call.

Please find below sample code how i am using this.

  cliRC = SQLForeignKeys(hstmt, NULL, 0, tbSchema, SQL_NTS, tbName, SQL_NTS,
NULL, 0, NULL, SQL_NTS, NULL, SQL_NTS);

 /* bind column 6 to variable */
  cliRC = SQLBindCol(hstmt, 6, SQL_C_CHAR, (SQLPOINTER)fkTableSch.val, 129,
&fkTableSch.ind);

  /* bind column 7 to variable */
  cliRC = SQLBindCol(hstmt, 7, SQL_C_CHAR, (SQLPOINTER)fkTableName.val, 129,
&fkTableName.ind);

  /* bind column 8 to variable */
  cliRC = SQLBindCol(hstmt, 8, SQL_C_CHAR, (SQLPOINTER)fkColumnName.val,
129, &fkColumnName.ind);

  /* fetch each row and display */
  WriteResultFile( "\nFetch each row and display.\n");

  /* fetch next row */
  cliRC = SQLFetch(hstmt);

  if (cliRC == SQL_NO_DATA_FOUND)
  {
WriteResultFile( "\nData not found.\n");
  }
 
 
  As a reference following are the quires which odbc driver is sending to
server for getting this information.
 
Query is [SELECTpt.tgargs,  pt.tgnargs, pt.tgdeferrable,
  pt.tginitdeferred,   pp1.proname,pp2.proname,pc.oid,
pc1.oid,pc1.relname,pt.tgconstrname, pn1.nspname FROM  
pg_catalog.pg_class pc, pg_catalog.pg_class pc1,   
pg_catalog.pg_proc pp,  pg_catalog.pg_proc pp1, pg_catalog.pg_proc
pp2, pg_catalog.pg_trigger pt,   pg_catalog.pg_trigger pt1, 
pg_catalog.pg_trigger pt2,  pg_catalog.pg_namespace pn,
pg_catalog.pg_namespace pn1 WHERE  pc.relname='DEPT321'AND pn.nspname =
'public'AND pc.relnamespace = pn.oidAND pt.tgconstrrelid =
pc.oid   AND pp.oid = pt.tgfoid  AND pp.proname Like '%ins'  AND
pt1.tgconstrname = pt.tgconstrname  AND pt1.tgconstrrelid = pt.tgrelid 
AND pt1.tgrelid = pc.oidAND pc1.oid = pt.tgrelidAND pp1.oid
= pt1.tgfoidAND pp1.proname like '%upd' AND (pp1.proname not
like '%check%')   AND pt2.tgconstrname = pt.tgconstrname   AND
pt2.tgconstrrelid = pt.tgrelid AND pt2.tgrelid = pc.oid AND
pp2.oid = pt2.tgfoidAND pp2.proname Like '%del' AND pn1.oid =
pc1.relnamespace  order by pt.tgconstrname]

***
Query is [select ta.attname, ia.attnum, ic.relname, n.nspname, tc.relname
from pg_catalog.pg_attribute ta, pg_catalog.pg_attribute ia,
pg_catalog.pg_class tc, pg_catalog.pg_index i, pg_catalog.pg_namespace n,
pg_catalog.pg_class ic where tc.relname = 'dept321' AND n.nspname = 'public'
AND tc.oid = i.indrelid AND n.oid = tc.relnamespace AND i.indisprimary = 't'
AND ia.attrelid = i.indexrelid AND ta.attrelid = i.indrelid AND ta.attnum =
i.indkey[ia.attnum-1] AND (NOT ta.attisdropped) AND (NOT ia.attisdropped)
AND ic.oid = i.indexrelid order by ia.attnum]

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Postgresql v8.3.3 + Perl v5.10

[Eugen.Konkov]

Yes, I am ActivePerl and Win32 Binary PG
Is it scheduled to fix?

- Original Message - 
From: "Pavel Stehule" <[EMAIL PROTECTED]>

To: "Peter Eisentraut" <[EMAIL PROTECTED]>
Cc: ; <[EMAIL PROTECTED]>; "Euler Taveira de 
Oliveira" <[EMAIL PROTECTED]>

Sent: Friday, August 22, 2008 12:20 PM
Subject: Re: [BUGS] Postgresql v8.3.3 + Perl v5.10



2008/8/22 Peter Eisentraut <[EMAIL PROTECTED]>:

[EMAIL PROTECTED] wrote:

1. Install Perl v5.10
2. Install PG
3. PG does not see that machine has Perl
4. Remove Perl and PG
5. Instll Perl v5.8
6. Install PG
7. PG work fine
Problem is that PG does not recognize Perl v5.10 =(


Please provide the actual commands and the actual output, not abstract
descriptions.

I can tell you that I am building and running PostgreSQL and Perl 5.10 
just
fine.  So the problem must be in the details, which are not evident from 
your

description.



This bug was reported I though. win installer doesn't recognize
installed Perl 5.10 and doesn't allow plperl installation.

Pavel


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs



--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs 



--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Postgresql v8.3.3 + Perl v5.10

[Pavel Stehule]

2008/8/22 Peter Eisentraut <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] wrote:
>> 1. Install Perl v5.10
>> 2. Install PG
>> 3. PG does not see that machine has Perl
>> 4. Remove Perl and PG
>> 5. Instll Perl v5.8
>> 6. Install PG
>> 7. PG work fine
>> Problem is that PG does not recognize Perl v5.10 =(
>
> Please provide the actual commands and the actual output, not abstract
> descriptions.
>
> I can tell you that I am building and running PostgreSQL and Perl 5.10 just
> fine.  So the problem must be in the details, which are not evident from your
> description.
>

This bug was reported I though. win installer doesn't recognize
installed Perl 5.10 and doesn't allow plperl installation.

Pavel

> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Postgresql v8.3.3 + Perl v5.10

[Magnus Hagander]

Peter Eisentraut wrote:
> [EMAIL PROTECTED] wrote:
>> 1. Install Perl v5.10
>> 2. Install PG
>> 3. PG does not see that machine has Perl
>> 4. Remove Perl and PG
>> 5. Instll Perl v5.8
>> 6. Install PG
>> 7. PG work fine
>> Problem is that PG does not recognize Perl v5.10 =(
> 
> Please provide the actual commands and the actual output, not abstract 
> descriptions.
> 
> I can tell you that I am building and running PostgreSQL and Perl 5.10 just 
> fine.  So the problem must be in the details, which are not evident from your 
> description.

I think he is talking about the Windows binary distribution. In which
case, the answer is no - the binary windows distribution of 8.3 does
*not* work with perl 5.10.

Other platforms, and build-from-source on Windows should, AFAIK.

//Magnus


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Postgresql v8.3.3 + Perl v5.10

[Peter Eisentraut]

[EMAIL PROTECTED] wrote:
> 1. Install Perl v5.10
> 2. Install PG
> 3. PG does not see that machine has Perl
> 4. Remove Perl and PG
> 5. Instll Perl v5.8
> 6. Install PG
> 7. PG work fine
> Problem is that PG does not recognize Perl v5.10 =(

Please provide the actual commands and the actual output, not abstract 
descriptions.

I can tell you that I am building and running PostgreSQL and Perl 5.10 just 
fine.  So the problem must be in the details, which are not evident from your 
description.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Postgresql v8.3.3 + Perl v5.10

[Eugen.Konkov]

1. Install Perl v5.10
2. Install PG
3. PG does not see that machine has Perl
4. Remove Perl and PG
5. Instll Perl v5.8
6. Install PG
7. PG work fine
Problem is that PG does not recognize Perl v5.10 =(
- Original Message - 
From: "Euler Taveira de Oliveira" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Cc: "Peter Eisentraut" <[EMAIL PROTECTED]>; 
Sent: Friday, August 22, 2008 3:00 AM
Subject: Re: [BUGS] Postgresql v8.3.3 + Perl v5.10



[EMAIL PROTECTED] escreveu:

Bug in that, that I install PG on server with perl 5.10 installed, but
PG fails to run any PLPERL code
How to fix?


Could you post some test case?


--
 Euler Taveira de Oliveira
 http://www.timbira.com/


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #4370: connectby method

[Derek & Bob]

The following bug has been logged online:

Bug reference:  4370
Logged by:  Derek & Bob
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.3.0
Operating system:   Linux
Description:connectby method
Details: 

I've got a question about table connectby method. Say, we have five elements
which are 1,2,3,4,5. Each of them are the roots in the tree.Instead of using
five connectby methods to generate them all in the table, I assume there is
a element 0, which is the parent of them, in the tree(which is not existed
in the real table). So only one  connectby is enough to get them all, and it
works. 


I don't know whether it's a bug or it's ok. Thanks.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #4369: connectby method

[Derek & Bob]

The following bug has been logged online:

Bug reference:  4369
Logged by:  Derek & Bob
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.3.0
Operating system:   Linux
Description:connectby method
Details: 

I've got a question about table connectby method. Say, we have five elements
which are 1,2,3,4,5. Each of them are the roots in the tree.Instead of using
five connectby methods to generate them all in the table, I assume there is
a element 0, which is the parent of them, in the tree(which is not existed
in the real table). So only one  connectby is enough to get them all, and it
works. 


I don't know whether it's a bug or it's ok. Thanks.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs