[BUGS] Bug #737: PQescapeBytea parameter #3 size_t *to_length
Christoph Haller ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
PQescapeBytea parameter #3 size_t *to_length
Long Description
Hi,
I am referring to
PostgreSQL 7.2.1 Documentation
Chapter 1. libpq - C Library
1.3. Command Execution Functions
1.3.3. Escaping binary strings for inclusion in SQL queries
I found the line
"The result string length does not include the terminating zero byte of the result."
is not right.
The result string length does indeed include the terminating zero byte.
When I do
binarystr = (char *)
PQescapeBytea((unsigned char *)"\01\02",2,(size_t *)&binarylen);
printf(" binarylen = %d \n", binarylen) ;
I'll get
binarylen = 3
I also dropped a DocNote, but unfortunately there is no way to
scroll on longer notes. Maybe you like to fix this, too.
Regards, Christoph
Sample Code
No file was uploaded with this report
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[BUGS] Bug #738: "order by" returning different results in 7.2 and 7.21
Kareem Badr ([EMAIL PROTECTED]) reports a bug with a severity of 1 The lower the number the more severe it is. Short Description "order by" returning different results in 7.2 and 7.21 Long Description When doing a query that uses the "order by" command, version 7.2 and version 7.21 return the records in a different order. All of the locale environment variables are identical, and the query is identical. Here is the comparison: bash-2.05$ hostname demo02.journyx.com bash-2.05$ locale LANG=en_US LC_CTYPE="en_US" LC_NUMERIC="en_US" LC_TIME="en_US" LC_COLLATE="en_US" LC_MONETARY="en_US" LC_MESSAGES="en_US" LC_PAPER="en_US" LC_NAME="en_US" LC_ADDRESS="en_US" LC_TELEPHONE="en_US" LC_MEASUREMENT="en_US" LC_IDENTIFICATION="en_US" LC_ALL= bash-2.05$ psql --version psql (PostgreSQL) 7.2 contains support for: readline, history, multibyte Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group Portions Copyright (c) 1996, Regents of the University of California Read the file COPYRIGHT or use the command \copyright to see the usage and distribution terms. id_user| pname ---+- amber | User Appenzeller_K | User bbunny| User Birdzell_D| User brad | User Bradshaw_P| User Brundage_C| User Chen_A| User Childs_D | User Cooney_A | User bash-2.04$ hostname dev2.int.journyx.com bash-2.04$ locale LANG=en_US LC_CTYPE="en_US" LC_NUMERIC="en_US" LC_TIME="en_US" LC_COLLATE="en_US" LC_MONETARY="en_US" LC_MESSAGES="en_US" LC_PAPER="en_US" LC_NAME="en_US" LC_ADDRESS="en_US" LC_TELEPHONE="en_US" LC_MEASUREMENT="en_US" LC_IDENTIFICATION="en_US" LC_ALL= bash-2.04$ psql --version psql (PostgreSQL) 7.2.1 Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group Portions Copyright (c) 1996, Regents of the University of California Read the file COPYRIGHT or use the command \copyright to see the usage and distribution terms. id_user| pname ---+- Appenzeller_K | User Birdzell_D| User Bradshaw_P| User Brundage_C| User Chen_A| User Childs_D | User Cooney_A | User amber | User bbunny| User brad | User Sample Code No file was uploaded with this report ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Bug #738: "order by" returning different results in 7.2 and 7.21
[EMAIL PROTECTED] writes: > When doing a query that uses the "order by" command, version 7.2 and > version 7.21 return the records in a different order. All of the > locale environment variables are identical, and the query is > identical. You are showing us the *client*'s locale environment, which has little to do with what the server's environment is, and even less to do with what locale initdb was run in. But it's initdb's locale that determines what the server will consider sort ordering to be. In this case it looks like the 7.2 server is using en_US (or something like it) while the 7.2.1 server is pretty clearly using C locale. If you don't like the setting you'll need to re-initdb ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Bug #725: ODBC driver problem with internal type PG_TYPE_TIMESTAMP_NO_TMZONE
This has been corrected in the current sources at odbc.postgresql.org. --- [EMAIL PROTECTED] wrote: > Martin Schenk ([EMAIL PROTECTED]) reports a bug with a severity of 2 > The lower the number the more severe it is. > > Short Description > ODBC driver problem with internal type PG_TYPE_TIMESTAMP_NO_TMZONE > > Long Description > When binding a column with the internal type PG_TYPE_TIMESTAMP_NO_TMZONE to a >SQL_C_TIMESTAMP variable, you always get the current date/time as result. > > Adding a line to recognize this format to the function "copy_and_convert_field" in >odbc/convert.c solves this problem. > > > > Sample Code > the problem is solved by adding the following: > >case PG_TYPE_ABSTIME: >case PG_TYPE_DATETIME: >case PG_TYPE_TIMESTAMP: > + case PG_TYPE_TIMESTAMP_NO_TMZONE > > in file convert.c (line 428), function "copy_and_convert_field" > (odbc driver shipped with postgres-7.2.1) > > No file was uploaded with this report > > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Bug #728: Interactions between bytea and character encoding
I am hoping for a patch for this for 7.3. Added to open items: Fix bytea to not encode input string --- Joe Conway wrote: > Joe Conway wrote: > > Bruce Momjian wrote: > > > >> Does this mean we don't have to esacpe >0x7f when inputting bytea > >> anymore? > > > > > > I seem to remember that bytea data was run through the multibute code > > for some reason, and I don't recall seeing that changed. ISTM that we > > shouldn't force bytea thought multibyte functions at all. > > > > The UNKNOWNIN patch did address part of the problem, just not all of it. > > Previously all 'unknown' data was initially cast as TEXT, and thus was > > subject to multibyte character set interpretation. But there was another > > execution path that was not dealt with. I'll search the archives for the > > thread. > > > > Here's the remaining issue that I remembered; see: >http://archives.postgresql.org/pgsql-hackers/2002-04/msg00256.php > > The gist of this is that when client and server encoding don't match, > pg_do_encoding_conversion() gets called, regardless of data type. This > is the *wrong thing* to do for BYTEA data, I think. Fixing this, > combined with the UNKNOWNIN/OUT fix we did earlier, should eliminate the > need to escape the high bit characters when inputting bytea. The only > characters which *should* need to be escaped are the ones originally > escaped by PQescapeBytea. IMHO of course ;-) > > Joe > > > Joe > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] Bug #728: Interactions between bytea and character encoding
Bruce Momjian wrote: > I am hoping for a patch for this for 7.3. Added to open items: > > Fix bytea to not encode input string > I said: > Here's the remaining issue that I remembered; see: > http://archives.postgresql.org/pgsql-hackers/2002-04/msg00256.php > > The gist of this is that when client and server encoding don't match, > pg_do_encoding_conversion() gets called, regardless of data type. > This is the *wrong thing* to do for BYTEA data, I think. Fixing this, > combined with the UNKNOWNIN/OUT fix we did earlier, should eliminate > the need to escape the high bit characters when inputting bytea. The > only characters which *should* need to be escaped are the ones > originally escaped by PQescapeBytea. IMHO of course ;-) Tatsuo or Tom can answer this better than me, but I don't think this can be fixed without a fe/be protocol change, so I'd guess it's a 7.4 issue. But, if there is a way to do it now, and someone gives me a clue how to proceed, I'll try to get a patch together. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] mistakes in postgresql-snapshots (7.3)
Is this something we need to address for 7.3? --- Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Oh, so createlang is fine, it is CREATE LANGUAGE that doesn't have the > > GRANT, but that makes sense. The problem is that 7.2.X pg_dump doesn't > > add the GRANT to the load script because we didn't have such permissions > > in 7.2.X. > > Right. Not only CREATE LANGUAGE, but CREATE FUNCTION, and for that > matter CREATE DATABASE, are going to have some issues of this sort > for people loading old dumps. > > > Wonder how we are going to fix that? > > I think we're gonna tell 'em to issue some manual GRANTs. > > regards, tom lane > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] mistakes in postgresql-snapshots (7.3)
Bruce Momjian <[EMAIL PROTECTED]> writes: > Is this something we need to address for 7.3? Peter pointed out that he'd already hacked pg_dump to do the right thing (or at least what is arguably the right thing) against older databases. That covers LANGUAGE, FUNCTION, and other objects-within- a-database cases. pg_dumpall doesn't yet do the right thing at the database level, but I believe he's planning to take care of that. A larger problem is that this only works if you use 7.3 pg_dump to dump your older database. If you dump with your then-current pg_dump, you'll be unhappy with the permissions that result after reloading into your new 7.3 server. I'm not sure there is anything we can do about this without making life worse. But it's annoying. Any thoughts? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Bug #737: PQescapeBytea parameter #3 size_t *to_length
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
[EMAIL PROTECTED] wrote:
> Christoph Haller ([EMAIL PROTECTED]) reports a bug with a severity of 3
> The lower the number the more severe it is.
>
> Short Description
> PQescapeBytea parameter #3 size_t *to_length
>
> Long Description
> Hi,
>
> I am referring to
>
> PostgreSQL 7.2.1 Documentation
> Chapter 1. libpq - C Library
> 1.3. Command Execution Functions
> 1.3.3. Escaping binary strings for inclusion in SQL queries
>
> I found the line
> "The result string length does not include the terminating zero byte of the result."
> is not right.
> The result string length does indeed include the terminating zero byte.
>
> When I do
>
> binarystr = (char *)
> PQescapeBytea((unsigned char *)"\01\02",2,(size_t *)&binarylen);
> printf(" binarylen = %d \n", binarylen) ;
>
> I'll get
> binarylen = 3
>
> I also dropped a DocNote, but unfortunately there is no way to
> scroll on longer notes. Maybe you like to fix this, too.
>
> Regards, Christoph
>
>
> Sample Code
>
>
> No file was uploaded with this report
>
>
> ---(end of broadcast)---
> TIP 4: Don't 'kill -9' the postmaster
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [BUGS] mistakes in postgresql-snapshots (7.3)
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Is this something we need to address for 7.3? > > Peter pointed out that he'd already hacked pg_dump to do the right > thing (or at least what is arguably the right thing) against older > databases. That covers LANGUAGE, FUNCTION, and other objects-within- > a-database cases. pg_dumpall doesn't yet do the right thing at the > database level, but I believe he's planning to take care of that. > > A larger problem is that this only works if you use 7.3 pg_dump > to dump your older database. If you dump with your then-current > pg_dump, you'll be unhappy with the permissions that result after > reloading into your new 7.3 server. > > I'm not sure there is anything we can do about this without making > life worse. But it's annoying. Any thoughts? Yep, it better be on our radar screen. Added to open items: Fix db, function, language permissions on 7.2 database loads -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
