[BUGS] text cast to bool bug
I think this is a funny bug:
select ('TRUE'::TEXT)::BOOL;
bool
--
f
but:
select ('TRUE'::varchar(4))::BOOL;
bool
--
t
or
select ('true'::TEXT)::BOOL;
bool
--
t
My postgresql version:
PostgreSQL 8.3.4
Laczi József
--
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] text cast to bool bug
Hello
It works on my server. Do you have a some specific configuration?
postgres=# select ('true'::text)::bool;
bool
--
t
(1 row)
I am checked 8.3, 8.4, 9.0.
Regards
Pavel Stehule
2010/3/18 Laczi József :
> I think this is a funny bug:
>
> select ('TRUE'::TEXT)::BOOL;
> bool
> --
> f
>
> but:
>
> select ('TRUE'::varchar(4))::BOOL;
> bool
> --
> t
> or
>
> select ('true'::TEXT)::BOOL;
> bool
> --
> t
>
>
> My postgresql version:
> PostgreSQL 8.3.4
>
>
> Laczi József
>
>
>
> --
> 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] text cast to bool bug
On Thu, Mar 18, 2010 at 11:37:53AM +0100, Pavel Stehule wrote:
> postgres=# select ('true'::text)::bool;
> bool
> --
> t
> (1 row)
>
> I am checked 8.3, 8.4, 9.0.
What about the 'TRUE' (all caps) case? Note the blow:
> 2010/3/18 Laczi József :
> > I think this is a funny bug:
> >
> > select ('TRUE'::TEXT)::BOOL;
> > bool
> > --
> > f
...
> > select ('true'::TEXT)::BOOL;
> > bool
> > --
> > t
--
"A search of his car uncovered pornography, a homemade sex aid, women's
stockings and a Jack Russell terrier."
- http://www.news.com.au/story/0%2C27574%2C24675808-421%2C00.html
--
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 #5378: Little inaccuracy in the manual
The following bug has been logged online: Bug reference: 5378 Logged by: lsasha Email address: sasha.mail...@gmail.com PostgreSQL version: 8.4.2 Operating system: Windows 7 Description:Little inaccuracy in the manual Details: Manual for PostgreSql 8.4 cantains a little inaccuracy in the Table 9.47. Session Information Functions chapter: current_query instead of current_query() Generally,Thanks for your pretty product. -- 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 #5377: group by problem
The following bug has been logged online: Bug reference: 5377 Logged by: michel rosa Email address: mr...@geomatic.ch PostgreSQL version: 8.3.10 Operating system: debian Description:group by problem Details: Hello, I have the following problem select to_char(upload_date, '-mm-dd'),cost,count(cost) from evadeo.tileshop where status=2 and source=3 and upload_date>='2010-03-01' and upload_date<='2010-03-02' group by to_char(upload_date, '-mm-dd'),cost order by to_char(upload_date, '-mm-dd'),cost give as result to_char | cost | count +--+--- 2010-03-01 |0 | 345 2010-03-01 | 0.5 |38 2010-03-01 |1 | 9 2010-03-01 | 1.5 | 164 2010-03-02 |0 | 837 2010-03-02 | 0.5 | 136 2010-03-02 | 1.5 | 138 but when upload_date<='2010-03-03', I get extras rows for 2010-03-02 select to_char(upload_date, '-mm-dd'),cost,count(cost) from evadeo.tileshop where status=2 and source=3 and upload_date>='2010-03-01' and upload_date<='2010-03-03' group by to_char(upload_date, '-mm-dd'),cost order by to_char(upload_date, '-mm-dd'),cost to_char | cost | count +--+--- 2010-03-01 |0 | 345 2010-03-01 | 0.5 |38 2010-03-01 |1 | 9 2010-03-01 | 1.5 | 164 2010-03-02 |0 | 1217 2010-03-02 | 0.5 | 287 2010-03-02 |1 | 11894 2010-03-02 | 1.5 | 379 2010-03-02 | 2.0 | 7 2010-03-02 | 3.0 | 3 2010-03-03 |0 | 7393 2010-03-03 | 0.5 |85 2010-03-03 | 1.5 | 152 do you have an explication ? Is it really a bug ? thanks -- 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 #5377: group by problem
"michel rosa" wrote: > I get extras rows for 2010-03-02 I'm not sure I understand your concern. Is it that the result set includes these rows?: > to_char | cost | count > +--+--- > 2010-03-02 | 2.0 | 7 > 2010-03-02 | 3.0 | 3 What do you get from?: select * from evadeo.tileshop where status=2 and source=3 and upload_date = '2010-03-02' and cost > 1.5; -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] text cast to bool bug
=?ISO-8859-2?Q?Laczi_J=F3zsef?= writes:
> I think this is a funny bug:
> select ('TRUE'::TEXT)::BOOL;
> bool
> --
> f
Works here:
regression=# select ('TRUE'::TEXT)::BOOL;
bool
--
t
(1 row)
(I'm checking 8.3.10, but that code hasn't changed in a long time.)
Maybe you have created a custom text-to-bool cast that is catching this
operation, and the cast function is case-sensitive?
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 #5377: group by problem
"michel rosa" writes: > ... > and upload_date<='2010-03-02' > give as result > 2010-03-02 |0 | 837 > 2010-03-02 | 0.5 | 136 > 2010-03-02 | 1.5 | 138 > but when upload_date<='2010-03-03', I get extras rows for 2010-03-02 Is the upload_date column actually a date? I think maybe it's a timestamp and the "extra" rows correspond to times after midnight. Your cutoff conditions are being interpreted as upload_date<='2010-03-02 00:00:00' etc. 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 #5378: Little inaccuracy in the manual
"lsasha" writes: > Manual for PostgreSql 8.4 cantains a little inaccuracy in > the Table 9.47. Session Information Functions chapter: > current_query instead of current_query() Hmm. Normally we're not very picky about that, but in that particular table I guess we need to be, since some of the other entries are for "functions" that need to be called without parentheses. Will 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
[BUGS] Error while altering an inheritance hierarchy in mid-query
My database implements partitioning using inheritance and constraint exclusion, as described in the fine manual. Each partition holds data for a single day, and there are well over 300 child partitions. The exception mentioned below notwithstanding, the technique works exceedingly well and is a real life saver when you have half a billion rows and climbing. While a query was running on the partition for today a maintenance job was run that summarizes data in a different partition using the technique described in section 5.9.3. - "Managing Partitions" of the manual, with a twist. Basically, it goes like this: 1. A select into query is run which summarizes the data from a partition into a table outside the inheritance hierarchy, which is then indexed. 2. Then a. a transaction is begun, b. the original partition is dropped, c. the new table renamed to the original partition's name, d. the new table's unique index is renamed, e. the appropriate check constraint is added, f. select privilege is granted, and g. the transaction is committed. So far so good, the maintenance job works fine and is quite speedy. The problem occurs when a select query is started prior to the sequence of events above, those steps complete, and an error is thrown saying "PGRES_FATAL_ERROR - ERROR: could not open relation with OID 64412". Of course, seconds later the query runs fine, and there is no object with OID 64412 in the database. It seems to me that removing and inserting partitions into the inheritance hierarchy may not be a consistent and/or isolated action with respect to queries that may be using the inheritance hierarchy. To be fair, this sequence of events doesn't normally happen in daily processing, but the behavior is not what I expected, nor is it mentioned in the manual. Am I missing or misinterpreting something? Thanks in advance for your advice! Bob Lunney -- 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] Error while altering an inheritance hierarchy in mid-query
Bob Lunney writes: > 1. A select into query is run which summarizes the data from a partition > into a table outside the inheritance hierarchy, which is then indexed. > 2. Then > a. a transaction is begun, > b. the original partition is dropped, > c. the new table renamed to the original partition's name, > d. the new table's unique index is renamed, > e. the appropriate check constraint is added, > f. select privilege is granted, and > g. the transaction is committed. I'd suggest taking an exclusive lock on the inheritance hierarchy's parent table between 2a and 2b. The "could not open relation with OID nnn" error is to be expected when a table is dropped just as a query is in the act of trying to open it, which is what could happen here if a query on the parent table runs concurrently with the DROP. You're also at risk that a concurrent query might see both or neither of the old and new versions of the partition, leading to bogus answers. Both of these things would be fixed if incoming queries are blocked while trying to open the parent table, rather than while iterating through the list of inheritance children for it. 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 #5379: Adding hunspell-ko dictionary for full-text search doesn't work
The following bug has been logged online: Bug reference: 5379 Logged by: Hyunsik Choi Email address: hyunsik.c...@gmail.com PostgreSQL version: 8.4 Operating system: Ubuntu Linux 9.10 and Gentoo Linux Description:Adding hunspell-ko dictionary for full-text search doesn't work Details: Hi, I tried to create text search dictionary with hunspell-ko as follow: First, I installed hunspell-ko, and I check if hunspell-ko dic is located in /usr/share/postgres/8.4/tsearch_data. And, I typed: CREATE TEXT SEARCH DICTIONARY korean_hunspell ( TEMPLATE = ispell, DictFile = system_ko, AffFile = system_ko ); But, postgres prints the following error: ERROR: wrong affix file format for flag CONTEXT: line 22489 of configuration file "/usr/share/postgresql/8.4/tsearch_data/system_ko.affix": "COMPOUNDMIN 1 " First, I think that hunspell-ko may be wrong. However, the hunspell-ko is being used for open office, firefox, and other applications. Anyone who can help me? Best regards, Hyunsik Choi http://diveintodata.org -- 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] Error while altering an inheritance hierarchy in mid-query
So I did miss something! Thanks for the brilliant explanation and simple solution, Tom. Bob --- On Thu, 3/18/10, Tom Lane wrote: > From: Tom Lane > Subject: Re: [BUGS] Error while altering an inheritance hierarchy in mid-query > To: "Bob Lunney" > Cc: pgsql-bugs@postgresql.org > Date: Thursday, March 18, 2010, 3:26 PM > Bob Lunney > writes: > > 1. A select into query is run which summarizes > the data from a partition into a table outside the > inheritance hierarchy, which is then indexed. > > 2. Then > > a. a transaction is begun, > > b. the original partition is > dropped, > > c. the new table renamed to the > original partition's name, > > d. the new table's unique index > is renamed, > > e. the appropriate check > constraint is added, > > f. select privilege is granted, > and > > g. the transaction is > committed. > > I'd suggest taking an exclusive lock on the inheritance > hierarchy's > parent table between 2a and 2b. The "could not open > relation with OID > nnn" error is to be expected when a table is dropped just > as a query > is in the act of trying to open it, which is what could > happen here if > a query on the parent table runs concurrently with the > DROP. > You're also at risk that a concurrent query might see both > or neither > of the old and new versions of the partition, leading to > bogus answers. > Both of these things would be fixed if incoming queries are > blocked > while trying to open the parent table, rather than while > iterating > through the list of inheritance children for it. > > > 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
