Tom Lane wrote:
that Oracle chooses to treat WITH-queries as if they were plain
sub-selects if they're non-recursive and only referenced once.
That is, Oracle would rewrite the above into
SELECT * FROM ( SELECT * FROM foo ) AS q WHERE key = 42;
and then flatten the sub-select and
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
2. The patch didn't touch the implicit-RTE code, which means that
WITH q AS ( SELECT ... )
SELECT q.*
will fail even if you've got add_missing_from enabled. I'm inclined
to think that this violates the principle of
Tom Lane wrote:
that Oracle chooses to treat WITH-queries as if they were plain
sub-selects if they're non-recursive and only referenced once.
That is, Oracle would rewrite the above into
SELECT * FROM ( SELECT * FROM foo ) AS q WHERE key = 42;
and then flatten the sub-select and
Gregory Stark [EMAIL PROTECTED] writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
2. The patch didn't touch the implicit-RTE code, which means that
WITH q AS ( SELECT ... )
SELECT q.*
will fail even if you've got add_missing_from enabled.
Yes, it's legacy. I wouldn't
David Fetter [EMAIL PROTECTED] writes:
How hard would it be to add the infrastructure for CYCLE?
Personally I'm more interested in getting the recursive UNION (without
ALL) case to work.
I think that this might just be a matter of drawing on support that's
already there: have RecursiveUnion
It fails on two of my machines like this:
*** src/test/regress/expected/int8.out Sun Oct 5 12:19:58 2008
--- src/test/regress/results/int8.out Sun Oct 5 12:20:26 2008
***
*** 748,756
(1 row)
SELECT CAST('9223372036854775807.0'::float4 AS int8);
! ERROR: bigint out of
Simon Riggs wrote:
OK, spent long time testing various batching scenarios for this using a
custom test harness to simulate various spreads of xids in transaction
trees. All looks fine now.
I had a look and was mostly rephrasing some comments and the README
(hopefully I didn't make any of them
Tom Lane wrote:
The buildfarm is showing still other interesting behaviors.
I'm not really interested in having umpteen expected int8 files
to deal with all the strange corner cases that might be seen
on different platforms. Please just remove all the edge-case
tests.
Yeah, it's probably not
Peter Eisentraut [EMAIL PROTECTED] writes:
This result from AIX/PPC can't be good, however:
Hmm. The test in int84div is
/*
* Overflow check.The only possible overflow case is for arg1 =
* INT64_MIN, arg2 = -1, where the correct result is -INT64_MIN, which
* can't be
Hi all,
While i'm testing the HEAD version of CVS with this new feature, i
found a possible bug and like that more persons could try it in you
own box.
The attached file is a log of my test and I'm using a unprivileged
user to do it.
Thanks.
--
[]s
Dickson S. Guedes
Dickson S. Guedes [EMAIL PROTECTED] writes:
While i'm testing the HEAD version of CVS with this new feature, i
found a possible bug and like that more persons could try it in you
own box.
Yeah, that's a bug (two different ones in fact). Fixed --- thanks for
the report!
There are a couple of open questions for parallel pg_restore.
First, we need a way to decide the boundary between the serially run
pre-data section and the remainder of the items in the TOC. Currently
the code uses the first TABLEDATA item as the boundary. That's not
terribly robust (what if
On Thu, 25 Sep 2008, Simon Riggs wrote:
So it would be useful to have a column that meant if I run the RESET
command it would return me to this value.
Patch v3 attached that exposes boot_val and reset_val. The docs for the
latter link to the RESET command page for details.
Sample, with
Another 0.02c, bringing the grand total to 0.04c.
Andrew Dunstan wrote:
First, we need a way to decide the boundary between the serially run
pre-data section and the remainder of the items in the TOC.
Currently the code uses the first TABLEDATA item as the boundary.
That's not terribly
14 matches
Mail list logo
