The following bug has been logged online:
Bug reference: 5479
Logged by: Kurt wagner
Email address: kurt.wag...@leoni.com
PostgreSQL version: 8.4
Operating system: HP-UX
Description:PosgreSQL Documentation does not mention OPEN
Details:
When checking the Web Site
ht
On 28/05/10 12:06, Kurt wagner wrote:
When checking the Web Site
http://www.postgresql.org/docs/8.4/static/sql-commands.html
I recognized that the commands "declare" and "close" are documented, but I
failed to find "open".
OPEN is not an SQL command like DECLARE and CLOSE. It is part of
PL/pg
On 2010-05-27, Piergiorgio Buongiovanni
wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5476
> Logged by: Piergiorgio Buongiovanni
> Email address: p.buongiova...@net-international.com
> PostgreSQL version: 8.3.4
> Operating system: CentOS (Redhat 5.4)
The following bug has been logged online:
Bug reference: 5480
Logged by: Sakari Maaranen
Email address: s...@iki.fi
PostgreSQL version: 8.4.4
Operating system: CentOS 5.5
Description:Autovacuum interferes with operations (e.g. truncate) on
very large databases
Details
I made a brute force check and indeed, for one of the parameters the query was
switching to sequential scans (or bitmaps scans with condition on survey_pk=16
only if sequential scans were off). After closer look at the plan cardinalities
I thought it would be worthy to increase histogram size an
The following bug has been logged online:
Bug reference: 5477
Logged by: Matt Nourse
Email address: matt...@nplus1.com.au
PostgreSQL version: 8.4
Operating system: Linux (Debian and Red Hat)
Description:CREATE DOMAIN NOT NULL constraints not always enforced
for INSERT
The following bug has been logged online:
Bug reference: 5478
Logged by: Markus
Email address: markus.her...@outpost24.com
PostgreSQL version: PostgreSQL 8.4.
Operating system: Ubuntu 10.04
Description:ILIKE operator returns wrong result
Details:
The following query
Markus wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5478
> Logged by: Markus
> Email address: markus.her...@outpost24.com
> PostgreSQL version: PostgreSQL 8.4.
> Operating system: Ubuntu 10.04
> Description:ILIKE operator returns wrong resul
"Sakari Maaranen" writes:
> The documentation also says that the quickest way to empty a whole table
> would be by using the truncate command. However, if the autovacuum daemon
> happens to be working on the same table, it causes the truncate command to
> hang for a very long time to wait the vacu
"Markus" writes:
> select 'ba' ilike '%__%';
> return true as expected in 8.2 but false in 8.4.
I have a feeling that this represents still another bug in the
special-case path for % followed by _ (cf bug #4821). If so,
maybe we ought to just toss out that optimization?
"Matt Nourse" writes:
> CREATE DOMAIN test_id_domain INT NOT NULL;
> CREATE TABLE test_state(id test_id_domain PRIMARY KEY, display_value
> varchar(20) NOT NULL);
> CREATE TABLE test_city(state_id test_id_domain REFERENCES test_state(id));
> This produces an error as expected:
> INSERT INTO tes
Tom Lane wrote:
> "Markus" writes:
> > select 'ba' ilike '%__%';
> > return true as expected in 8.2 but false in 8.4.
>
> I have a feeling that this represents still another bug in the
> special-case path for % followed by _ (cf bug #4821). If so,
> maybe we ought to just toss out that optimizat
Bruce Momjian writes:
> Tom Lane wrote:
>> I have a feeling that this represents still another bug in the
>> special-case path for % followed by _ (cf bug #4821). If so,
>> maybe we ought to just toss out that optimization?
> Yea, looks like it is this code in like_match.c:
No, actually it's th
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I have a feeling that this represents still another bug in the
> >> special-case path for % followed by _ (cf bug #4821). If so,
> >> maybe we ought to just toss out that optimization?
>
> > Yea, looks like it is this code in like_
Bruce Momjian writes:
> Tom Lane wrote:
>> If tlen == 0 when we reach this loop, we'll fall through and fail.
>> But that is wrong since we need to consider the possibility that
>> the remaining pattern can match a zero-length substring. So the
>> loop needs to be changed to attempt a recursive M
I wrote:
> No, that patch is just plain wrong. It eats %'s that would affect
> the later recursive MatchText calls.
Hmm ... actually, it's not wrong, but it's not good either. What we
really ought to do here is not just eat _'s following %, but eat *any
mixture of* % and _, advancing over a text
BTW, while I'm looking at this, I notice that there was an oversight in
the change that made us throw an error for \ at the end of the LIKE
pattern. We throw error in the first code chunk that deals with \
but we don't do so here:
if (plen < 2)
Tom Lane wrote:
> "Matt Nourse" writes:
> > CREATE DOMAIN test_id_domain INT NOT NULL;
> > CREATE TABLE test_state(id test_id_domain PRIMARY KEY, display_value
> > varchar(20) NOT NULL);
> > CREATE TABLE test_city(state_id test_id_domain REFERENCES test_state(id));
>
> > This produces an error a
Tom Lane wrote:
> BTW, while I'm looking at this, I notice that there was an oversight in
> the change that made us throw an error for \ at the end of the LIKE
> pattern. We throw error in the first code chunk that deals with \
> but we don't do so here:
>
> if (plen
I have added the following TODO:
Fix FETCH_COUNT to handle SELECT ... INTO and WITH queries
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01565.php
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00192.php
-
Added to TODO:
Prevent psql from sending remaining single-line multi-statement queries
after reconnection
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00159.php
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01283.php
---
Daniele Varrazzo wrote:
> "If there is no match to the pattern, the function returns no rows" is
> easily overlooked as "it returns null", or some other behaviour that
> don't change the returned set. The point is, because the function is
> listed in the string function, you would expect the functi
22 matches
Mail list logo
