Added to TODO:
Add support for WITH RECURSIVE ... CYCLE
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg00291.php
---
Tom Lane wrote:
I looked a bit at the SQL:2008 spec for a CYCLE clause for WITH
On Mon, Oct 13, 2008 at 07:01:29PM -0400, Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
On Mon, Oct 13, 2008 at 9:56 AM, Tom Lane [EMAIL PROTECTED] wrote:
I'm inclined to apply the patch with binary-coercibility
adjustments and not try to turn RECORD or RECORD[] into
Merlin Moncure [EMAIL PROTECTED] writes:
Here is another use-case solved by the patch. Previously, there was
no easy way to index on a composite function result. The following
works in HEAD:
create function func(f foo, a out int, b out int) returns record ...
create index foo_idx on
On Mon, Oct 13, 2008 at 7:01 PM, Tom Lane [EMAIL PROTECTED] wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
On Mon, Oct 13, 2008 at 9:56 AM, Tom Lane [EMAIL PROTECTED] wrote:
I'm inclined to apply the patch with binary-coercibility adjustments
and not try to turn RECORD or RECORD[] into
On Tue, Oct 14, 2008 at 10:59 AM, Tom Lane [EMAIL PROTECTED] wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
Here is another use-case solved by the patch. Previously, there was
no easy way to index on a composite function result. The following
works in HEAD:
create function func(f foo, a
On Wed, Oct 8, 2008 at 4:27 PM, Tom Lane [EMAIL PROTECTED] wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
On Tue, Oct 7, 2008 at 9:58 PM, Tom Lane [EMAIL PROTECTED] wrote:
* Instead of the above, we could try to make
ROW(some columns) = ANY (array variable)
work. This is shorter than the
Merlin Moncure [EMAIL PROTECTED] writes:
The record ops work as promised. IMO this patch stands in its own
merits with or without the CTE changes. I played around with it and
noticed a couple of oddities:
select foo = foo from foo; --works
but
select distinct foo from foo; --yields
I wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
select foo from foo order by foo;
ERROR: could not identify an ordering operator for type foo
Yeah, these are because of the incomplete handling of named record
types. I'm not sure how far we want to go in that direction.
On looking
On Mon, Oct 13, 2008 at 9:56 AM, Tom Lane [EMAIL PROTECTED] wrote:
I wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
select foo from foo order by foo;
ERROR: could not identify an ordering operator for type foo
Yeah, these are because of the incomplete handling of named record
types. I'm
Merlin Moncure [EMAIL PROTECTED] writes:
On Mon, Oct 13, 2008 at 9:56 AM, Tom Lane [EMAIL PROTECTED] wrote:
I'm inclined to apply the patch with binary-coercibility adjustments
and not try to turn RECORD or RECORD[] into full-fledged polymorphic
types. It's not immediately clear what the use
Tom Lane escribió:
Merlin Moncure [EMAIL PROTECTED] writes:
On Mon, Oct 13, 2008 at 9:56 AM, Tom Lane [EMAIL PROTECTED] wrote:
I'm inclined to apply the patch with binary-coercibility adjustments
and not try to turn RECORD or RECORD[] into full-fledged polymorphic
types. It's not
On Tue, Oct 7, 2008 at 9:58 PM, Tom Lane [EMAIL PROTECTED] wrote:
* Instead of the above, we could try to make
ROW(some columns) = ANY (array variable)
work. This is shorter than the above syntax and would presumably have
a lot less overhead too. But it doesn't work right now, not
Merlin Moncure [EMAIL PROTECTED] writes:
On Tue, Oct 7, 2008 at 9:58 PM, Tom Lane [EMAIL PROTECTED] wrote:
* Instead of the above, we could try to make
ROW(some columns) = ANY (array variable)
work. This is shorter than the above syntax and would presumably have
a lot less overhead too. But
I looked a bit at the SQL:2008 spec for a CYCLE clause for WITH
RECURSIVE. It is interesting to see that it is just syntactic sugar,
because *they spell out how to expand it into regular SQL*. More,
they defined it in such a way that it's hard to optimize at all,
because the path column is
14 matches
Mail list logo
