I think Jonah is referring to the the 'START WITH ... CONNECT BY'
clause feature from Oracle. Am I right Jonah?
For such queries, Oracle introduces a pseudocolumn LEVEL, that
holds the value of the indentation level of the current rusultant row.
In Oracle, the LEVEL column returns 0 for
On Tue, May 16, 2006 at 03:18:19PM +0530, Gurjeet Singh wrote:
LEVEL might not be a part of the standard, but it is very handy
when dealing with hierarchical queries.
The chapter 1 (http://www.oreilly.com/catalog/sqlpr/chapter/ch01.pdf)
of book 'SQL Pocket Guide' elaborates more on it.
Martijn van Oosterhout kleptog@svana.org writes:
I'm assuming that what's actually being implemented is the SQL standard
method with the Oracle alternative being another way of specifying the
same thing?
What's being implemented should be the standard. Full stop.
On 5/16/06, Martijn van Oosterhout kleptog@svana.org wrote:
I'm assuming that what's actually being implemented is the SQL standard
method with the Oracle alternative being another way of specifying the
same thing?
I'm working on both versions of hierarchical queries; CONNECT BY for
Hey everyone,
I'm reworking hierarchical queries and am adding a LEVEL pseudocolumn.
As it's a totally calculated attribute, what's the best way to handle
it keeping in mind that LEVEL is only used in a hierarchical query?
Looking at Evgen's patches, if he recognizes a hierarchical query and
On Mon, May 15, 2006 at 11:03:46AM -0400, Jonah H. Harris wrote:
I couldn't think of any pseudocolumns like this in PostgreSQL, but I
may just be brain-dead again. As it may be sorta similar, how were we
discussing handling rownum?
tableoid is a pseudo-column like you mean, perhaps you should
On 5/15/06, Martijn van Oosterhout kleptog@svana.org wrote:
tableoid is a pseudo-column like you mean, perhaps you should look how
that works.
I thought tableoid was a system column with a physical representation
on the tuple itself? I don't want any on-disk representation of my
On Mon, May 15, 2006 at 11:17:41AM -0400, Jonah H. Harris wrote:
On 5/15/06, Martijn van Oosterhout kleptog@svana.org wrote:
tableoid is a pseudo-column like you mean, perhaps you should look how
that works.
I thought tableoid was a system column with a physical representation
on the tuple
Martijn van Oosterhout kleptog@svana.org writes:
All you need to do is decide where you are going to store the level
number and add it as a system attribute (negative attribute number).
This could only work if LEVEL is guaranteed to have one and only one
value per tuple. I'm not too sure about
On 5/15/06, Tom Lane [EMAIL PROTECTED] wrote:
This could only work if LEVEL is guaranteed to have one and only one
value per tuple. I'm not too sure about the spec but it seems like
that'd probably fall down in join situations.
Yes, this was another thing handled by Evgen's patch... FakeVar
Jonah H. Harris [EMAIL PROTECTED] writes:
I'm reworking hierarchical queries and am adding a LEVEL pseudocolumn.
As it's a totally calculated attribute, what's the best way to handle
it keeping in mind that LEVEL is only used in a hierarchical query?
Perhaps you should start by explaining
11 matches
Mail list logo
