Thread: misc questions
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
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