Looks like hierarchical queries are now officially stalled :(
Anyone want to take this up for 8.1?
Chris
Original Message
Subject: Re: [HACKERS] SQL99 Hierarchical queries
Date: Sun, 15 May 2005 07:31:16 +0400
From: Evgen Potemkin [EMAIL PROTECTED]
Reply-To: Evgen Potemkin [EMAIL
I'm planning to change ExecRestrPos and the routines it calls so that
an updated TupleTableSlot holding the restored-to tuple is explicitly
returned.
Currently, since nothing is explicitly done to the result Slot of a
plan node when we restore its position, you might think that the Slot
still
Bruce Momjian pgman@candle.pha.pa.us writes:
Hmm. That particular case will work, but the planner believes that only
consecutive columns in the index are usable --- that is, if you have
quals for a and c but not for b, it will think that the condition for c
isn't usable with the index.
On Wed, 4 May 2005 21:37:40 -0700, Josh Berkus josh@agliodbs.com
wrote:
As stated above, these system views, once incorporated into a pg distribution,
are likely to be with us *forever*.
I don't think that this is doable. :-(
You might want to put the system views into a version specific
On Thu, 12 May 2005 17:40:06 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
the planner believes that only
consecutive columns in the index are usable --- that is, if you have
quals for a and c but not for b, it will think that the condition for c
isn't usable with the index. This is true for btree
Greg Stark [EMAIL PROTECTED] writes:
Bruce Momjian pgman@candle.pha.pa.us writes:
Hmm. That particular case will work, but the planner believes that only
consecutive columns in the index are usable --- that is, if you have
quals for a and c but not for b, it will think that the condition for
On Sun, 15 May 2005, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Bruce Momjian pgman@candle.pha.pa.us writes:
Hmm. That particular case will work, but the planner believes that only
consecutive columns in the index are usable --- that is, if you have
quals for a and c but not for b, it
I wrote:
Currently, since nothing is explicitly done to the result Slot of a
plan node when we restore its position, you might think that the Slot
still points at the tuple that was current just before the Restore.
You'd be wrong though, at least for seqscan and indexscan plans
(I haven't
[Moved to -hackers]
On Sat, May 14, 2005 at 11:32:23AM -0400, Tom Lane wrote:
So what we've got [for DROP USER] is:
1. Reject if any references to user from within other databases
(implementation restriction).
2. Reject if user owns any databases or tablespaces (safety feature).
3. If
On Sun, 2005-05-15 at 15:09 -0400, Tom Lane wrote:
I'm planning to change ExecRestrPos and the routines it calls so that
an updated TupleTableSlot holding the restored-to tuple is explicitly
returned.
Currently, since nothing is explicitly done to the result Slot of a
plan node when we
Alvaro Herrera [EMAIL PROTECTED] writes:
Additionally we need to think what should happen if the user is the
grantor of some privilege. I think we should warn in RESTRICT mode, and
in CASCADE, revoke the privilege from the grantee.
You mean fail in RESTRICT mode, no?
Hmm. We could
I suppose you are running on some BSD variant? BSD is notorious for
promising more than it can deliver with respect to number of open files
per process. This is a kernel bug, not a Postgres bug.
You can adjust Postgres' max_files_per_process setting to compensate for
the kernel's lying about its
On Sun, May 15, 2005 at 05:48:56PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Additionally we need to think what should happen if the user is the
grantor of some privilege. I think we should warn in RESTRICT mode, and
in CASCADE, revoke the privilege from the grantee.
About this time last year I was holding forth on the value of visiting
the heap in TID order, even when index scan tuples are randomly ordered.
Today I decided to start working on the problem stated in this TODO
item:
Fetch heap pages matching index entries in sequential order
On Sun, May 15, 2005 at 04:44:57PM +0800, Christopher Kings-Lynne wrote:
Looks like hierarchical queries are now officially stalled :(
Anyone want to take this up for 8.1?
Sergei and Jason,
Feel like taking SQL:1999 WITH RECURSIVE? It would be a giant help to
the PostgreSQL community. :)
Jeffrey W. Baker [EMAIL PROTECTED] writes:
I see that Tom has already done the infrastructure work by adding
getmulti, but getmulti isn't used by nodeIndexscan.c, only
nodeBitmapIndexscan.c. Will btree index scans be executed by creating
in-memory bitmaps in 8.1, or will some scans still be
16 matches
Mail list logo
