[BUGS] BUG #6215: ODBC - ovelflow with the OIDs - Large Objects
The following bug has been logged online: Bug reference: 6215 Logged by: eamanuel Email address: eaman...@gmail.com PostgreSQL version: 8.4 Operating system: Opernsuse 11.3 Description:ODBC - ovelflow with the OIDs - Large Objects Details: Hello my name is Manuel and I've a problem when in de DB the OIDs's values are upper than 2147483647 (integer max values), but the ODBC 8.04.02 don't support values uppers than 2147483647 but in the DB it is allowed . The field support because it is a oid type. Any suggestion? 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 #6216: Calling PQconnectdbParams from C++ with a char**
The following bug has been logged online:
Bug reference: 6216
Logged by: Lionel Elie Mamane
Email address: lio...@mamane.lu
PostgreSQL version: 9.1.0
Operating system: Debian GNU/Linux
Description:Calling PQconnectdbParams from C++ with a char**
Details:
In C++, a char** value is not convertible to a const char** value,
because that is not safe (see
http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.17).
This means one cannot call libpq's PQconnectdbParams and friends passing
them a char** value for keywords and/or values, as these arguments are
declared const char**.
So please apply this patch, which declares them char const* const*
instead, which is:
- equivalent to const char * const*; use that one if you prefer
- still true, since libpq won't write to they keyword/values arrays
- allows to pass a char** to them and be recognised by a C++ compiler as
OK without a cast.
This patch is licensed under a do whatever you want with it license.
Thanks in advance.
--- postgresql-9.1-9.1.0.orig/src/interfaces/libpq/fe-connect.c
+++ postgresql-9.1-9.1.0/src/interfaces/libpq/fe-connect.c
@@ -291,8 +291,8 @@ static void freePGconn(PGconn *conn);
static void closePGconn(PGconn *conn);
static PQconninfoOption *conninfo_parse(const char *conninfo,
PQExpBuffer errorMessage, bool use_defaults);
-static PQconninfoOption *conninfo_array_parse(const char **keywords,
-const char **values, PQExpBuffer
errorMessage,
+static PQconninfoOption *conninfo_array_parse(char const* const*keywords,
+char const* const*values, PQExpBuffer
errorMessage,
bool use_defaults, int expand_dbname);
static char *conninfo_getval(PQconninfoOption *connOptions,
const char *keyword);
@@ -362,8 +362,8 @@ pgthreadlock_t pg_g_threadlock = default
* call succeeded.
*/
PGconn *
-PQconnectdbParams(const char **keywords,
- const char **values,
+PQconnectdbParams(char const* const*keywords,
+ char const* const*values,
int expand_dbname)
{
PGconn *conn = PQconnectStartParams(keywords, values,
expand_dbname);
@@ -381,8 +381,8 @@ PQconnectdbParams(const char **keywords,
* check server status, accepting parameters identical to
PQconnectdbParams
*/
PGPing
-PQpingParams(const char **keywords,
-const char **values,
+PQpingParams(char const* const*keywords,
+char const* const*values,
int expand_dbname)
{
PGconn *conn = PQconnectStartParams(keywords, values,
expand_dbname);
@@ -464,8 +464,8 @@ PQping(const char *conninfo)
* See PQconnectPoll for more info.
*/
PGconn *
-PQconnectStartParams(const char **keywords,
-const char **values,
+PQconnectStartParams(char const* const*keywords,
+char const* const*values,
int expand_dbname)
{
PGconn *conn;
@@ -4249,7 +4249,7 @@ conninfo_parse(const char *conninfo, PQE
* keywords will take precedence, however.
*/
static PQconninfoOption *
-conninfo_array_parse(const char **keywords, const char **values,
+conninfo_array_parse(char const* const*keywords, char const* const*values,
PQExpBuffer errorMessage, bool
use_defaults,
int expand_dbname)
{
--- postgresql-9.1-9.1.0.orig/src/interfaces/libpq/libpq-fe.h
+++ postgresql-9.1-9.1.0/src/interfaces/libpq/libpq-fe.h
@@ -235,14 +235,14 @@ typedef struct pgresAttDesc
/* make a new client connection to the backend */
/* Asynchronous (non-blocking) */
extern PGconn *PQconnectStart(const char *conninfo);
-extern PGconn *PQconnectStartParams(const char **keywords,
-const char **values, int
expand_dbname);
+extern PGconn *PQconnectStartParams(char const* const*keywords,
+char const* const*values, int
expand_dbname);
extern PostgresPollingStatusType PQconnectPoll(PGconn *conn);
/* Synchronous (blocking) */
extern PGconn *PQconnectdb(const char *conninfo);
-extern PGconn *PQconnectdbParams(const char **keywords,
- const char **values, int expand_dbname);
+extern PGconn *PQconnectdbParams(char const* const*keywords,
+ char const* const*values, int expand_dbname);
extern PGconn *PQsetdbLogin(const char *pghost, const char *pgport,
const char *pgoptions, const char *pgtty,
const char *dbName,
@@ -413,8 +413,8 @@ extern int PQsetnonblocking(PGconn *conn
extern int PQisnonblocking(const PGconn *conn);
extern int
[BUGS] BUG #6217: to_char() gives incorrect output for very small float values
The following bug has been logged online: Bug reference: 6217 Logged by: Chris Gernon Email address: kabi...@gmail.com PostgreSQL version: 9.1.0 Operating system: Windows XP Description:to_char() gives incorrect output for very small float values Details: The to_char() function gives incorrect output for float values whose decimal expansion has several digits (more than somewhere around 14-15) after the decimal point. To reproduce: CREATE TABLE t ( id serial, f double precision, CONSTRAINT t_pk PRIMARY KEY (id) ); INSERT INTO t (f) VALUES (0.000563219288); SELECT to_char(f, 'FM90.99') FROM t WHERE id = 1; Expected Output: 0.000563219288 Actual Output: 0. SELECT to_char(f, '90.99') FROM t WHERE id = 1; Expected Output: 0.00056321928800 Actual Output: 0.00 -- 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 #6217: to_char() gives incorrect output for very small float values
Chris Gernon kabi...@gmail.com wrote: The to_char() function gives incorrect output for float values whose decimal expansion has several digits (more than somewhere around 14-15) after the decimal point. These are approximate data types. On what basis do you think the values returned in your examples are wrong? The demonstrated results don't surprise me, given that they match to about the limits of the approximate data type involved. It also wouldn't surprise me to see slightly different results on different architectures or operating systems. If you want exact values, you should use a type which supports that, like numeric. -Kevin -- 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 #6217: to_char() gives incorrect output for very small float values
Chris Gernon kabi...@gmail.com writes: CREATE TABLE t ( id serial, f double precision, CONSTRAINT t_pk PRIMARY KEY (id) ); INSERT INTO t (f) VALUES (0.000563219288); SELECT to_char(f, 'FM90.99') FROM t WHERE id = 1; Expected Output: 0.000563219288 Actual Output: 0. My immediate reaction to that is that float8 values don't have 57 digits of precision. If you are expecting that format string to do something useful you should be applying it to a numeric column not a double precision one. It's possible that we can kluge things to make this particular case work like you are expecting, but there are always going to be similar-looking cases that can't work because the precision just isn't there. (In a quick look at the code, the reason you just get 0. is that it's rounding off after 15 digits to ensure it doesn't print garbage. Maybe it could be a bit smarter for cases where the value is very much smaller than 1, but it wouldn't be a simple change.) 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 #6217: to_char() gives incorrect output for very small float values
Christopher Gernon kabi...@gmail.com wrote: to_char() should be able to convert 5.6e-32 to text just as easily as it can convert 5.6e-3. For some reason, it doesn't. Oh, I see your point now, and I agree with you. We should probably at least put this on the TODO list, I think. Any objections? -Kevin -- 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 #6217: to_char() gives incorrect output for very small float values
Kevin Grittner kevin.gritt...@wicourts.gov writes: Christopher Gernon kabi...@gmail.com wrote: to_char() should be able to convert 5.6e-32 to text just as easily as it can convert 5.6e-3. For some reason, it doesn't. Oh, I see your point now, and I agree with you. We should probably at least put this on the TODO list, I think. Any objections? If we're gonna fix it, we should just fix it, I think. I was considering taking a stab at it, but if someone else would like to, that's fine too. One other thing I notice in the same area is that the handling of NaNs and infinities seems a bit incomplete. There's an explicit special case for them in the -format code path, but not otherwise, and I think that the results you get for other formats will vary depending on what the local implementation of snprintf does. What *should* the output be, if the input is NaN or Inf? 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 #6217: to_char() gives incorrect output for very small float values
On Tue, Sep 20, 2011 at 1:39 PM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: These are approximate data types. On what basis do you think the values returned in your examples are wrong? The demonstrated Because PostgreSQL still has access to all the significant digits: test1=# SELECT f FROM t WHERE id = 1; f - 5.63219288e-032 (1 row) Since floats are stored with a significand and an exponent, to_char() should be able to convert 5.6e-32 to text just as easily as it can convert 5.6e-3. For some reason, it doesn't. -- 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 #6217: to_char() gives incorrect output for very small float values
Tom Lane t...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: Christopher Gernon kabi...@gmail.com wrote: to_char() should be able to convert 5.6e-32 to text just as easily as it can convert 5.6e-3. For some reason, it doesn't. Oh, I see your point now, and I agree with you. We should probably at least put this on the TODO list, I think. Any objections? If we're gonna fix it, we should just fix it, I think. I was considering taking a stab at it, but if someone else would like to, that's fine too. I wouldn't mind doing it, but not until after the CF wraps. On the other hand, isn't this is one of those compatibility functions? Perhaps it would best be done by someone who has familiarity with, and access to, a database with which we're trying to be compatible. -Kevin -- 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 #6217: to_char() gives incorrect output for very small float values
Kevin Grittner kevin.gritt...@wicourts.gov writes: Tom Lane t...@sss.pgh.pa.us wrote: If we're gonna fix it, we should just fix it, I think. I was considering taking a stab at it, but if someone else would like to, that's fine too. I wouldn't mind doing it, but not until after the CF wraps. On the other hand, isn't this is one of those compatibility functions? Perhaps it would best be done by someone who has familiarity with, and access to, a database with which we're trying to be compatible. Chris already stated that the case gives the answer he expects in several other DBs, so I don't seem much need for further compatibility checking on the don't round off prematurely angle. However, it would be interesting to know what Oracle etc do with NaN and Infinity, assuming they even support such numbers. Currently what our code does for the format-with- case is to output # in all digit positions. It would be plausible for that to happen in the non- cases too, but whether that's actually what happens in other systems is something I don't know. 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 #6217: to_char() gives incorrect output for very small float values
Tom Lane t...@sss.pgh.pa.us wrote: it would be interesting to know what Oracle etc do with NaN and Infinity, assuming they even support such numbers. Currently what our code does for the format-with- case is to output # in all digit positions. It would be plausible for that to happen in the non- cases too, but whether that's actually what happens in other systems is something I don't know. From a quick web search, it looks like '#' filling is the typical approach for infinity and NaN. -Kevin -- 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 #6217: to_char() gives incorrect output for very small float values
On Tue, Sep 20, 2011 at 8:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, it would
be interesting to know what Oracle etc do with NaN and Infinity,
assuming they even support such numbers.
Note that it looks like NUMBER cannot store either Infinity or NaN.
They can only occur in BINARY_FLOAT and BINARY_DOUBLE. From the docs:
If a BINARY_FLOAT or BINARY_DOUBLE value is converted to CHAR or NCHAR, and
the input is either infinity or NaN (not a number), then Oracle always
returns the pound signs to replace the value.
And testing shows:
SQL select to_char(cast('NAN' as binary_float), 'FM.') from dual;
TO_CHAR(CA
--
##
SQL select to_char(cast('-Inf' as binary_float), 'FM.') from dual;
TO_CHAR(CA
--
##
SQL select to_char(cast('+Inf' as binary_float), 'FM.') from dual;
TO_CHAR(CA
--
##
--
greg
--
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 #6217: to_char() gives incorrect output for very small float values
Greg Stark st...@mit.edu writes:
On Tue, Sep 20, 2011 at 8:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, it would
be interesting to know what Oracle etc do with NaN and Infinity,
assuming they even support such numbers.
Note that it looks like NUMBER cannot store either Infinity or NaN.
They can only occur in BINARY_FLOAT and BINARY_DOUBLE. From the docs:
If a BINARY_FLOAT or BINARY_DOUBLE value is converted to CHAR or NCHAR, and
the input is either infinity or NaN (not a number), then Oracle always
returns the pound signs to replace the value.
And testing shows:
SQL select to_char(cast('NAN' as binary_float), 'FM.') from dual;
TO_CHAR(CA
--
##
Hmm, interesting. They replace the whole field with '#', not just the
digit positions? Because that's not what is happening in our code at
the moment, for the one case where we consider this at all:
regression=# select to_char('nan'::float8, '.');
to_char
.
(1 row)
The path seems rather broken in some other ways as well:
regression=# select to_char('43.5'::float8, '.');
to_char
-
4.3500e+01
(1 row)
Since I did not say FM, why is it suppressing leading spaces here?
I'm starting to think that that code needs a wholesale rewrite
(not but what that's true of just about every part of formatting.c).
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 #6216: Calling PQconnectdbParams from C++ with a char**
On Tue, Sep 20, 2011 at 11:05 AM, Lionel Elie Mamane lio...@mamane.lu wrote:
The following bug has been logged online:
Bug reference: 6216
Logged by: Lionel Elie Mamane
Email address: lio...@mamane.lu
PostgreSQL version: 9.1.0
Operating system: Debian GNU/Linux
Description: Calling PQconnectdbParams from C++ with a char**
Details:
In C++, a char** value is not convertible to a const char** value,
because that is not safe (see
http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.17).
This means one cannot call libpq's PQconnectdbParams and friends passing
them a char** value for keywords and/or values, as these arguments are
declared const char**.
So please apply this patch, which declares them char const* const*
instead, which is:
- equivalent to const char * const*; use that one if you prefer
- still true, since libpq won't write to they keyword/values arrays
- allows to pass a char** to them and be recognised by a C++ compiler as
OK without a cast.
This patch is licensed under a do whatever you want with it license.
Thanks in advance.
--- postgresql-9.1-9.1.0.orig/src/interfaces/libpq/fe-connect.c
+++ postgresql-9.1-9.1.0/src/interfaces/libpq/fe-connect.c
@@ -291,8 +291,8 @@ static void freePGconn(PGconn *conn);
static void closePGconn(PGconn *conn);
static PQconninfoOption *conninfo_parse(const char *conninfo,
PQExpBuffer errorMessage, bool use_defaults);
-static PQconninfoOption *conninfo_array_parse(const char **keywords,
- const char **values, PQExpBuffer
errorMessage,
+static PQconninfoOption *conninfo_array_parse(char const* const*keywords,
+ char const* const*values,
PQExpBuffer errorMessage,
bool use_defaults, int expand_dbname);
static char *conninfo_getval(PQconninfoOption *connOptions,
const char *keyword);
@@ -362,8 +362,8 @@ pgthreadlock_t pg_g_threadlock = default
* call succeeded.
*/
PGconn *
-PQconnectdbParams(const char **keywords,
- const char **values,
+PQconnectdbParams(char const* const*keywords,
+ char const* const*values,
int expand_dbname)
{
PGconn *conn = PQconnectStartParams(keywords, values,
expand_dbname);
@@ -381,8 +381,8 @@ PQconnectdbParams(const char **keywords,
* check server status, accepting parameters identical to
PQconnectdbParams
*/
PGPing
-PQpingParams(const char **keywords,
- const char **values,
+PQpingParams(char const* const*keywords,
+ char const* const*values,
int expand_dbname)
{
PGconn *conn = PQconnectStartParams(keywords, values,
expand_dbname);
@@ -464,8 +464,8 @@ PQping(const char *conninfo)
* See PQconnectPoll for more info.
*/
PGconn *
-PQconnectStartParams(const char **keywords,
- const char **values,
+PQconnectStartParams(char const* const*keywords,
+ char const* const*values,
int expand_dbname)
{
PGconn *conn;
@@ -4249,7 +4249,7 @@ conninfo_parse(const char *conninfo, PQE
* keywords will take precedence, however.
*/
static PQconninfoOption *
-conninfo_array_parse(const char **keywords, const char **values,
+conninfo_array_parse(char const* const*keywords, char const* const*values,
PQExpBuffer errorMessage, bool
use_defaults,
int expand_dbname)
{
--- postgresql-9.1-9.1.0.orig/src/interfaces/libpq/libpq-fe.h
+++ postgresql-9.1-9.1.0/src/interfaces/libpq/libpq-fe.h
@@ -235,14 +235,14 @@ typedef struct pgresAttDesc
/* make a new client connection to the backend */
/* Asynchronous (non-blocking) */
extern PGconn *PQconnectStart(const char *conninfo);
-extern PGconn *PQconnectStartParams(const char **keywords,
- const char **values, int
expand_dbname);
+extern PGconn *PQconnectStartParams(char const* const*keywords,
+ char const* const*values, int
expand_dbname);
extern PostgresPollingStatusType PQconnectPoll(PGconn *conn);
/* Synchronous (blocking) */
extern PGconn *PQconnectdb(const char *conninfo);
-extern PGconn *PQconnectdbParams(const char **keywords,
- const char **values, int expand_dbname);
+extern PGconn *PQconnectdbParams(char const* const*keywords,
+ char const* const*values, int
expand_dbname);
extern PGconn *PQsetdbLogin(const char *pghost, const char *pgport,
const char *pgoptions, const char *pgtty,
Re: [BUGS] BUG #6216: Calling PQconnectdbParams from C++ with a char**
Craig Ringer ring...@ringerc.id.au writes: As for wording: my *personal* preference is const char * const but I don't know what the opinions of those who work with the code day-to-day are. +1. Isn't the other ordering deprecated by recent C standards? (Or maybe I'm just thinking of where you're supposed to put static, but in any case char const * looks pretty weird to me.) Also, the existing usages in libpq-fe.h look like that, and there's no good reason for these to be randomly different. 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
