Re: [BUGS] Postgres 9.2.2 Bug in Select with Left Join
"liebehenz" writes: > i have here a strange bug. Can't really say anything about this without a self-contained test case (which your screenshot isn't, even if it were 100% readable). However, are you sure that it's 9.2.2 and not 9.2.1 that's wrong? There were several planner bugs fixed in between. 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] Postgres 9.2.2 Bug in Select with Left Join
liebehenz wrote: > a_name (char var 48) is sometimes empty in the select of the new 9.2.2 > Version, > > the a_name is in the table column set. > > Something is going wrong. > here in screenshot same identical database on 9.2.1 Server and 9.2.2 Server Character-based results are preferred on a list like this. A psql session is good. A self-contained test case (which take things from creation and population of test data through to the misbehavior is ideal). For starters can you show us (copy/paste) the results of running this in psql?: \d artikel select a_id, char_length(a_name), a_name from artikel where a_id in (323, 324); -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Arbitrary whitespace restrictions on range types
Jeff, Hackers: Is there a strong reason why this has to error? postgres=# select '[,]'::TSTZRANGE postgres-# ; tstzrange --- (,) (1 row) postgres=# select '[, ]'::TSTZRANGE; ERROR: invalid input syntax for type timestamp with time zone: " " LINE 1: select '[, ]'::TSTZRANGE --Josh -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.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] Arbitrary whitespace restrictions on range types
On 18 December 2012 23:31, Josh Berkus wrote: > Jeff, Hackers: > > Is there a strong reason why this has to error? Having taken a look at the range I/O routines, I surmise that it was just easier to write range_parse() such that whitespace is included within tokens: * Whitespace before or after is ignored. Whitespace within a * is taken literally and becomes part of the input string for that bound. I think that escaping the underlying literal values for parsing is a surprisingly difficult task, so I can see why the implementation would shrug in this case. This behaviour may be astonishing, but that doesn't make it a POLA violation. I don't have time to check now, but I'm pretty sure that doing something else would break a whole bunch of other common cases. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] Arbitrary whitespace restrictions on range types
On Wed, 2012-12-19 at 00:06 +, Peter Geoghegan wrote: > On 18 December 2012 23:31, Josh Berkus wrote: > > Jeff, Hackers: > > > > Is there a strong reason why this has to error? > > Having taken a look at the range I/O routines, I surmise that it was > just easier to write range_parse() such that whitespace is included > within tokens: There was some discussion about it, and the decision was made to match record literal parsing for the sake of consistency. In a record literal, spaces are considered to be a part of the value, so they are for range types, as well. Regards, Jeff Davis -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
