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

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

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

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

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

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