hello david,
i did some quick testing with this wonderful patch.
it seems there are some flaws in there still:
test=# explain select count(*)
test-# from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL
SELECT DISTINCT n+1 FROM t )
test(# SELECT * FROM t WHERE n
Gregory Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Couldn't we just have it pay attention to the existing
max_stack_depth?
Recursive query does not consume stack. The server enters an infinite
loop without consuming stack. Stack-depth error does not happen.
Alvaro Herrera wrote:
Bruce Momjian wrote:
I think the case for it got a whole lot weaker in 8.3, with lazy
consumption of CIDs.
Agreed. Let's see if we get requests for it in = 8.3 releases.
In the original submission message you find this text:
: attached is our patch
Tom Lane wrote:
Hans-Juergen Schoenig [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
Question for Hans-Juergen and Zoltan: have you tested 8.3 and do you
still see the need for this?
i have seen this problem two or three times within the past 2-3 years or
so. so, it can
On Mar 23, 2008, at 9:25 PM, Volkan YAZICI wrote:
Hi,
On Sun, 23 Mar 2008, Martin Pihlak [EMAIL PROTECTED] writes:
Attached is a patch that enables tracking function calls through
the stats subsystem. Original discussion:
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00377.php
On Feb 11, 2008, at 10:26 AM, Heikki Linnakangas wrote:
Hans-Juergen Schoenig wrote:
Last week we have seen a problem with some horribly configured
machine.
The disk filled up (bad FSM ;) ) and once this happened the
sysadmi killed the system (-9).
After two days PostgreSQL has still
Last week we have seen a problem with some horribly configured machine.The disk filled up (bad FSM ;) ) and once this happened the sysadmi killed the system (-9).After two days PostgreSQL has still not started up and they tried to restart it again and again making sure that the consistency check
good morning everybody,this is a working version of evgen potemkin's patch implementing CONNECT BY. it has been ported to 8.3 and it seems to work flawlessly with CVS head.it is not supposed to be included into 8.4 but i guess it might be useful for some people.there are still some limitations and
Remember that we were talking about supporting views, not tables. And
if a view uses a slow query then you are in immediate danger of having a
slow COPY. This may not be a problem but it needs to be discussed and
an agreement must be reached before introducing such a change (and not
during
Alvaro Herrera wrote:
Hans-Juergen Schoenig wrote:
Remember that we were talking about supporting views, not tables. And
if a view uses a slow query then you are in immediate danger of having a
slow COPY. This may not be a problem but it needs to be discussed and
an agreement must
Remember that we were talking about supporting views, not tables. And
if a view uses a slow query then you are in immediate danger of having a
slow COPY. This may not be a problem but it needs to be discussed and
an agreement must be reached before introducing such a change (and not
during
On the other hand I don't see why you are arguing in favor of a useless
feature whose coding is dubious; you can have _the same thing_ with nice
code and no discussion.
Because of [1] and because Mr. Schoenig's arguments
about changing schemas.
first of all; hans is enough - skip the mr
this.
Would you redo this against current CVS? Thanks.
---
Hans-Juergen Schoenig wrote:
Folks,
We have implemented SELECT FOR UPDATE NOWAIT for PostgreSQL.
The patch attached to this email contains all the required
Geschwinde Hans-Juergen Schoenig
--
Cybertec Geschwinde u Schoenig GmbH.
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/660/816 40 77
www.cybertec.at, www.postgresql.at
diff -r -c postgresql-8.0.0rc2.orig/doc/src/sgml/ref/select.sgml postgresql-8.0.0rc2/doc/src/sgml/ref/select.sgml
*** postgresql
14 matches
Mail list logo
