[BUGS] BUG #4862: different results in to_date() between 8.3.7 & 8.4.RC1
The following bug has been logged online: Bug reference: 4862 Logged by: Jeremy Ford Email address: jeremf...@gmail.com PostgreSQL version: 8.4 RC1 Operating system: Fedora 10 i386 Description:different results in to_date() between 8.3.7 & 8.4.RC1 Details: Running the following query on PG 8.3.7 select to_char(2009,'') as year, to_char(3,'09') as month, to_date(to_char(2009,'')||to_char(3,'99') ,'MM') as method1, to_date(to_char(2009,'')||'-'||to_char(3,'09') || '-01','-MM-DD') as method2 results in: year, month, method1, method2 " 2009";" 03";"2009-03-01";"2009-03-01" Running exactly the same query on PG 8.4.RC1 gives: year, month, method1, method2 " 2009";" 03";"0200-09-01";"2009-03-01" PG 8.3.7“method1” = "2009-03-01" PG 8.4.RC1 “method1” = "0200-09-01" Both databases were on the same machine – Fedora 10 – 32bit (GCC 4.3.2). Server configured for Australian timezone/usage. I realize I should have slapped a trim() around the to_char(), but thought it worth noting the difference anyway. Cheers, Jeremy. -- 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 #4861: Incorrect log_line_prefix default value in postgresql.conf
On Thu, Jun 18, 2009 at 11:44 PM, Milen A. Radev wrote: > Tom Lane написа: >> >> "Dmitry Ryabov" writes: >>> >>> Description: Incorrect log_line_prefix default value in >>> postgresql.conf >> >>> log_line_prefix = '%%t ' >>> (must be log_line_prefix = '%t ') >> >> Uh, the default setting is an empty string. Are you sure this is >> not your own error? If it isn't, perhaps it is a problem in some >> packaging of Postgres, but you did not say which package you are >> using. > > The line looks like that after using the One-click installer available here > - http://www.enterprisedb.com/products/pgdownload.do. > > Probably should be sorted out by EnterpriseDB. Thanks - on it. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.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 #4863: postgresql.conf typo in log_line_prefix
The following bug has been logged online: Bug reference: 4863 Logged by: Jan-Peter Seifert Email address: jan-peter.seif...@gmx.de PostgreSQL version: 8.4 RC1 Operating system: Windows Description:postgresql.conf typo in log_line_prefix Details: log_line_prefix is set to '%%t' So it shows '%t' instead of a time stamp. P.S. Where can I ask questions about the changes from the first/second beta in: lc_monetary (lc_ etc.): 'German, Germany' instead of 'German_Germany.1252' default_text_search_config: 'pg_catalog.simple' instead of 'pg_catalog.german' Why is log_min_messages set to warning by default in 8.4? Thank you very much, Peter -- 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 #4864: rc1 not installs on Windows
The following bug has been logged online: Bug reference: 4864 Logged by: pasman Email address: pasma...@gmail.com PostgreSQL version: 8.4rc1 Operating system: WinXP sp2 Description:rc1 not installs on Windows Details: I run postgresql-8.4.0-rc1-1-windows.exe from http://www.enterprisedb.com/products/pgdownload.do and get message: File postgresql.conf not found (this is the translation, original is: Nie moge znalezc pliku postgresql.conf in polish) Database cluster is not created. -- 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 #4865: replace function returns null
The following bug has been logged online: Bug reference: 4865 Logged by: Jamolkhon Khakimov Email address: jkhaki...@gmail.com PostgreSQL version: 8.2.7 Operating system: Linux Description:replace function returns null Details: I dont know if it's a bug or not. It just seems illogical to me. replace( 'abcdefabcdef', 'cd', 'XX') // returns 'abXXefabXXef', ok replace( 'abcdefabcdef', 'XX', 'YY') // returns 'abcdefabcdef', ok replace( 'abcdefabcdef', 'XX', null) // returns null, while it should return 'abcdefabcdef' Sorry if that's not a bug. Could find anything related to this in the documentation. -- 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 #4862: different results in to_date() between 8.3.7 & 8.4.RC1
"Jeremy Ford" writes:
> select
> to_char(2009,'') as year,
> to_char(3,'09') as month,
> to_date(to_char(2009,'')||to_char(3,'99') ,'MM') as method1,
> to_date(to_char(2009,'')||'-'||to_char(3,'09') || '-01','-MM-DD')
> as method2
Or, eliminating the extraneous stuff, the point is that
regression=# select to_date(' 2009 07', 'MM');
to_date
0200-09-01
(1 row)
doesn't do what it used to. Ordinarily I might say "well, if you want
leading spaces you need to say that in the format", viz
regression=# select to_date(' 2009 07', ' MM');
to_date
2009-07-01
(1 row)
However, that just begs the question --- it seems that leading space is
allowed in MM, just not in . Brendan, is that intentional or is it
a 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 #4865: replace function returns null
"Jamolkhon Khakimov" writes: > replace( 'abcdefabcdef', 'XX', null) > // returns null, while it should return 'abcdefabcdef' No, it should return null. Like most Postgres functions, replace is strict, meaning it returns null if any input is null. This is sensible in the abstract because an unknown input means the result is unknown too. I suppose your argument is that the result here could be determined without knowing what the third argument value is, but the mechanism doesn't attempt to make such a fine distinction. 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 #4862: different results in to_date() between 8.3.7 & 8.4.RC1
2009/6/19 Tom Lane :
> regression=# select to_date(' 2009 07', ' MM');
> to_date
>
> 2009-07-01
> (1 row)
>
> However, that just begs the question --- it seems that leading space is
> allowed in MM, just not in . Brendan, is that intentional or is it
> a bug?
>
The reason the space between and MM is ignored isn't to do with
any special treatment of MM, rather it's to do with special treatment
of the end-of-string. Observe:
postgres=# select to_date('200906 19', 'MMDD');
to_date
2009-06-19
(1 row)
What's going on here is that from_char_parse_int_len() has two
different approaches to capturing characters from the input. The
normal mode is to pull an exact number of characters out of the
string, as per the format node; for DD we pull 2 characters, for
we pull 4, and so on. However, if the FM (fill mode) flag is given,
or if the next node is known to be a non-digit character, we take a
much more tolerant approach and let strtol() grab as many characters
as it cares to. [1]
The reason for this technique is that it allows us to get away with
things like this:
postgres=# select to_date('2-6-2009', 'DD-MM-');
to_date
2009-06-02
(1 row)
Or, to put it another way, the presence of separator characters trumps
a strict character-by-character interpretation of the format string.
The code treats the end-of-string as such a separator, so in your '
MM' example, the code lets strtol() off its leash and all the
remaining characters are fed into the month field.
This special treatment of separators was actually in the code long
before I got my hands on it, and I wasn't keen to change it -- I
feared that flipping that little quirk on its head would cause even
more breakage.
I hope that answers your question. to_date() is by nature a weird
beast with many strange corners in its behaviour, and it's hard to
strike a balance between backwards compatibility and Least
Astonishment. My personal preference would be for a 100% strict
interpretation of the format pattern, and a pox on anyone who has been
relying on sloppy patterns! But that's not very practical. I would
welcome any suggestions for further refinements.
Cheers,
BJ
[1] src/backend/utils/adt/formatting.c:1846
--
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 #4862: different results in to_date() between 8.3.7 & 8.4.RC1
Brendan Jurd writes: > I hope that answers your question. to_date() is by nature a weird > beast with many strange corners in its behaviour, and it's hard to > strike a balance between backwards compatibility and Least > Astonishment. My personal preference would be for a 100% strict > interpretation of the format pattern, and a pox on anyone who has been > relying on sloppy patterns! But that's not very practical. I would > welcome any suggestions for further refinements. My feeling about it is that we usually try to match Oracle's behavior for to_date/to_char, so the $64 question is whether Oracle allows a leading space in these same cases. Anyone have it handy to test? 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
[BUGS] BUG #4866: ECPG and BYTEA
The following bug has been logged online: Bug reference: 4866 Logged by: Rick Levine Email address: richard_d_lev...@raytheon.com PostgreSQL version: 8.3.7 Operating system: Windows Vista Description:ECPG and BYTEA Details: ECPG does not handle BYTEA columns properly. When I encode a unsigned char array using PQescapeByteaConn and send it to the server, it is not stored as the original bytes, but rather is stored as the escaped string (much larger). //This doesn't work. Stored encoded. bytea_var = PQescapeByteaConn(connection, bytea_hostvar, bytea_len, &new_len); EXEC SQL AT :connection INSERT INTO Btable (index, bytea_col) VALUES (:index_var, :bytea_var); //This doesn't work. Stored encoded. bytea_var = PQescapeByteaConn(connection, bytea_hostvar, bytea_len, new_len); EXEC SQL AT :connection INSERT INTO Btable (index, bytea_col) VALUES (:index_var, decode(:bytea_var, 'escape')); //This doesn't work. Error. bytea_var = PQescapeByteaConn(connection, bytea_hostvar, bytea_len, new_len); EXEC SQL AT :connection INSERT INTO Btable (index, bytea_col) VALUES (:index_var, :bytea_var::BYTEA); Furthermore, when I fetch the BYTEA column value back, I have to decode it twice (using PQunescapeBytea) to get back the original array of bytes. I see three problems. I have to use functions from the C interface, not documented as part of ECPG, to get this to work at all; my storage size is quadrupled on disk; and the data communicated between the client and server is even bigger than that. The problem, as I see it, is that there's no way for the ECPG parser to unequivocally determine the size of the byte array pointed to by the host variable. Sure, if it's declared as EXEC SQL BEGIN DECLARE SECTION; unsigned char bytea_hostvar[1024]; EXEC SQL END DECLARE SECTION; you can figure it out, but otherwise not. That is how I declared it BTW. This causes the need to create a null terminated string to send to the server, rather than just sending the original bytes. We know the coder knows the size of the buffer, but ECPG doesn't, so the best solution (to my mind) would be to allow the coder to tell ECPG the buffer size directly. A clean way to do this would be to allow an indicator variable containing the size, e.g. EXEC SQL BEGIN DECLARE SECTION; unsigned char bytea_hostvar[1024]; int hostvar_ind = 1024; EXEC SQL END DECLARE SECTION; EXEC SQL AT :connection INSERT INTO Btable (index, bytea_col) VALUES (:index_var, :bytea_hostvar:hostvar_ind); I'm just sayin... ;) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
