,
--
Yoshiyuki Asaba
[EMAIL PROTECTED]
if i am not totally wrong, this should give us a different result.
i am looking forward to see this patch in core :).
it is simply wonderful ...
many thanks,
hans
On Jul 3, 2008, at 1:11 AM, David Fetter wrote
{18,7} | 18-7
{26,13} | 26-13
{26,1} | 26-1
{26,12} | 26-12
{38,6} | 38-6
{38,17,9} | 38-17-9
{38,17,8} | 38-17-8
{38,15,10} | 38-15-10
{38,15,5,2} | 38-15-5-2
{38,15,5,3} | 38-15-5-3
(11 rows)
Regards,
--
Yoshiyuki Asaba
[EMAIL PROTECTED]
--
Sent via pgsql
;
count
---
100
(1 row)
Regards,
--
Yoshiyuki Asaba
[EMAIL PROTECTED]
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
;
if (tuplestore_gettupleslot(node-ss.ps.state-es_tuplestorestate,
true, slot))
return slot;
Regards,
--
Yoshiyuki Asaba
[EMAIL PROTECTED]
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
?
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.
Regards,
--
Yoshiyuki Asaba
[EMAIL PROTECTED]
--
Sent via pgsql-patches mailing list
to deal with infinite streams of records.
I think it's the other way around. The server should not emit infinite
number of records.
How about adding new GUC parameter max_recursive_call?
Regards,
--
Yoshiyuki Asaba
[EMAIL PROTECTED]
--
Sent via pgsql-patches mailing list (pgsql-patches
AS (SELECT 2)
SELECT * FROM x UNION ALL SELECT * FROM y;
?column?
--
1
2
(2 rows)
Regards,
--
Yoshiyuki Asaba
[EMAIL PROTECTED]
Index: src/backend/nodes/copyfuncs.c
===
RCS file: /projects/cvsroot/pgsql/src
(excluding connections establishing)
Regards,
--
Yoshiyuki Asaba
[EMAIL PROTECTED]
Index: pgbench.c
===
RCS file: /projects/cvsroot/pgsql/contrib/pgbench/pgbench.c,v
retrieving revision 1.74
diff -c -r1.74 pgbench.c
*** pgbench.c 15
| grep -w gram.\[cy\] | grep -v plpgsql
-rw-r--r-- pgsql/pgsql 237506 2006-11-06 07:42
postgresql-8.2.4/src/backend/parser/gram.y
-rw-r--r-- pgsql/pgsql 1040559 2007-04-20 14:13
postgresql-8.2.4/src/backend/parser/gram.c
--
Yoshiyuki Asaba
[EMAIL PROTECTED]
---(end
clean.bat. It deletes the files generated by Bison. I
think we don't have to delete these files.
The attached patch for HEAD is fixed them.
Regards,
--
Yoshiyuki Asaba
[EMAIL PROTECTED]
Index: Mkvcbuild.pm
===
RCS file: /projects/cvsroot
to 8.1.x and 8.0.x?
Regards,
--
Yoshiyuki Asaba
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get
to CREATEROLE.
Regards,
--
Yoshiyuki Asaba
[EMAIL PROTECTED]
Index: gram.y
===
RCS file: /projects/cvsroot/pgsql/src/backend/parser/gram.y,v
retrieving revision 2.521
diff -c -r2.521 gram.y
*** gram.y 29 Dec 2005 04:53:18 - 2.521
,
--
Yoshiyuki Asaba
[EMAIL PROTECTED]
*** parse_expr.c.orig 2005-01-13 02:32:36.0 +0900
--- parse_expr.c2005-05-22 17:12:37.0 +0900
***
*** 18,23
--- 18,24
#include catalog/pg_operator.h
#include catalog/pg_proc.h
#include commands/dbcommands.h
+ #include
postmaster starting
C:\msys\1.0\home\y-asabapostmaster.exe: invalid argument: '-D'
Try postmaster.exe --help for more information.
Attache patches for this problem.
--
Yoshiyuki Asaba
[EMAIL PROTECTED]
--- postmaster.c.orig Sun Aug 29 14:06:46 2004
+++ postmaster.cMon Sep 6 15:43
14 matches
Mail list logo
