On 5/16/06, Martijn van Oosterhout 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
EnterpriseDB and WITH [RECUR
Martijn van Oosterhout 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.
regards, tom lane
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
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 the
"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 explaini
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
Martijn van Oosterhout 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 the spec but it
On Mon, May 15, 2006 at 11:17:41AM -0400, Jonah H. Harris wrote:
> On 5/15/06, Martijn van Oosterhout 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
On 5/15/06, Martijn van Oosterhout 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
pseudocolumn... just assigned a
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 shou
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
fin
11 matches
Mail list logo
