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
> 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-
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.
>>
>> Y
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 m
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 th
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 r
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 i
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 d
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
13 matches
Mail list logo
