Skip site navigation (1) Skip section navigation (2)

'natural join' core dump

From: "Mark Hollomon" <mhh(at)nortelnetworks(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: 'natural join' core dump
Date: 2000-06-26 20:22:19
Message-ID: 3957BB7B.70D7EA91@americasm01.nt.com (view raw or flat)
Thread:
Lists: pgsql-hackers
postgresql 7.0.2
HPUX 10.20

configure --without-CXX --prefix=$HOME/pgsql --enable-cassert --enable-debug

create table a ( a integer, b integer );
create table b ( b integer, c integer );
create table c ( c integer, d integer );

-- core dumps
select * from a natural join b natural join c;
-- so does this
select * from a join b using (b) join c using (c);
-- this seems to work
select * from a join b on a.b = b.b join c on b.c = c.c;

back trace from the 'natural join' form shows:
#0  0xfef54 in parseFromClause (pstate=0x401caac8, frmList=0x401ca9e0) at parse_clause.c:505
#1  0xfe248 in makeRangeTable (pstate=0x401caac8, frmList=0x401ca9e0) at parse_clause.c:57
#2  0xf0958 in transformSelectStmt (pstate=0x401caac8, stmt=0x401ca9f8) at analyze.c:1417
#3  0xee208 in $0000001A () at analyze.c:238
#4  0xedbe8 in parse_analyze (pl=0x401caab0, parentParseState=0x0) at analyze.c:75
#5  0xfd9f4 in parser (str=0x40091628 "select * from a natural join b natural join c\n", typev=0x0, 
    nargs=0) at parser.c:64
#6  0x1724a8 in pg_parse_and_rewrite (
    query_string=0x40091628 "select * from a natural join b natural join c\n", typev=0x0, nargs=0, 
    aclOverride=0 '\000') at postgres.c:395
#7  0x172974 in pg_exec_query_dest (
    query_string=0x40091628 "select * from a natural join b natural join c\n", dest=Debug, 
    aclOverride=0 '\000') at postgres.c:580
#8  0x1728fc in pg_exec_query (
    query_string=0x40091628 "select * from a natural join b natural join c\n") at postgres.c:562
#9  0x1742d8 in $00000061 () at postgres.c:1590
#10 0xed150 in main (argc=3, argv=0x7b03ac00) at main.c:103


The debug output shows it doing the first join correctly. It seems
to flake when it is running the attributes of the join to find the
correct attribute for the second join.

-- 

Mark Hollomon
mhh(at)nortelnetworks(dot)com
ESN 451-9008 (302)454-9008

Responses

pgsql-hackers by date

Next:From: Giles LeanDate: 2000-06-26 21:00:41
Subject: Re: Proposal: More flexible backup/restore via pg_dump
Previous:From: Lamar OwenDate: 2000-06-26 18:49:00
Subject: [Fwd: RE: config.sub and config.guess for PostgreSQL compilation on Linux S/390]

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group