Hi folks

Few questions..

1: Has anyone found a way to fake INNER JOINS, basically I'm helping someone
convert some MSSQL code over to Postgres and they use INNER JOINS heavly

2: Have any of y'all ever seeen this error

""transformExpr: does not know how to transform node 501 (internal error)"

from statement:

"SELECT DISTINCT ss.stateID, ss.stateValue FROM State ss INNER JOIN Standard
st ON ss.stateID = st.stateID"

  It stikes me as kinda strange because first and formost it should complain about
the INNER JOIN and not this other thing.        


3: what is the maximum depth of nested sub queries ?

4: just out of the blue, how great or not great is our alpha support ?

Jeff



Tue, 9 May 2000 15:53:43 -0300 (ADT)
Jeff MacDonald <jeff@pgsql.com>
misc questions
Jeff MacDonald <jeff@pgsql.com> writes:
> 1: Has anyone found a way to fake INNER JOINS, basically I'm helping someone
> convert some MSSQL code over to Postgres and they use INNER JOINS heavly

You shouldn't have to fake it --- Thomas alleges that INNER JOIN syntax
works now.

> 2: Have any of y'all ever seeen this error

> ""transformExpr: does not know how to transform node 501 (internal error)"

> from statement:

> "SELECT DISTINCT ss.stateID, ss.stateValue FROM State ss INNER JOIN Standard
> st ON ss.stateID = st.stateID"

Congratulations, our first 7.0 bug report!  It fails for me too.  501 is
type T_List, so it looks like some list-slinging is going wrong.

> 3: what is the maximum depth of nested sub queries ?

No hard and fast limit, but they might be pretty slow if you nest them
real deep ... sub-selects aren't implemented especially efficiently ...

> 4: just out of the blue, how great or not great is our alpha support ?

Er ... what?

			regards, tom lane

Tue, 09 May 2000 16:39:35 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: misc questions 
On Tue, 9 May 2000, Tom Lane wrote:

> > 4: just out of the blue, how great or not great is our alpha support ?
> 
> Er ... what?

Alpha, as in the computer ... 

According to:

http://www.postgresql.org/users-lounge/7.0/docs/admin/ports.htm#AEN284

we're good to go on:

Compaq Tru64 5.0
Linux 2.0.x



Tue, 9 May 2000 18:13:29 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: misc questions 
> http://www.postgresql.org/users-lounge/7.0/docs/admin/ports.htm#AEN284
> we're good to go on:
> Compaq Tru64 5.0
> Linux 2.0.x

As noted on that page, published patches are required for the Linux
version (probably due to 64 bit issues with the function manager).

                     - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Wed, 10 May 2000 05:44:02 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: misc questions
Thomas,

I looked at Jeff MacDonald's gripe:

Jeff MacDonald <jeff@pgsql.com> writes:
> 2: Have any of y'all ever seeen this error
> ""transformExpr: does not know how to transform node 501 (internal error)"
> from statement:
> "SELECT DISTINCT ss.stateID, ss.stateValue FROM State ss INNER JOIN Standard
> st ON ss.stateID = st.stateID"

(which behavior is in fact duplicated in the join regress test!) and
find that it looks like it would work, except that there is confusion in
the parser about whether pstate->p_join_quals is a list of expressions
or just an expression.

As far as I can see, there is no need for it to be a list, so we have
a choice of fixing it either by consistently making it be a list, or
consistently making it *not* be a list.  I'd lean to the latter on
grounds of simplicity, but I wonder whether you intended it to be
a list because you were looking forward to some currently-unimplemented
feature that does need it to be a list.

Comments?

			regards, tom lane

Wed, 10 May 2000 20:58:38 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: misc questions 
> > 2: Have any of y'all ever seeen this error
> > ""transformExpr: does not know how to transform node 501 (internal error)"
> > from statement:
> > "SELECT DISTINCT ss.stateID, ss.stateValue FROM State ss INNER JOIN Standard
> > st ON ss.stateID = st.stateID"
> 
> (which behavior is in fact duplicated in the join regress test!) and
> find that it looks like it would work, except that there is confusion in
> the parser about whether pstate->p_join_quals is a list of expressions
> or just an expression.
> 
> As far as I can see, there is no need for it to be a list, so we have
> a choice of fixing it either by consistently making it be a list, or
> consistently making it *not* be a list.  I'd lean to the latter on
> grounds of simplicity, but I wonder whether you intended it to be
> a list because you were looking forward to some currently-unimplemented
> feature that does need it to be a list.

I'm not recalling anything requiring a list here. Lists are floating
around for other cases (e.g. the USING clause). Not sure why this
wasn't caught in the regression test earlier (but clearly it was
because I didn't spot it :(

I'd be inclined to go with the non-list, simplest solution; we know
where to look if it needs to be augmented later.

                      - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Thu, 11 May 2000 05:47:45 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: misc questions
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I'd be inclined to go with the non-list, simplest solution; we know
> where to look if it needs to be augmented later.

Roger, will work on that.

			regards, tom lane

Thu, 11 May 2000 02:26:50 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: misc questions 