Re: Why my manualy constructed raw parser tree produce failed to execute? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Why my manualy constructed raw parser tree produce failed to execute?
Date
Msg-id AANLkTim-K_q7yDQIFWwmd18THJ_wYDovcd2CYBvDPOq3@mail.gmail.com
Whole thread Raw
In response to Re: Why my manualy constructed raw parser tree produce failed to execute?  (Mohammad Heykal Abdillah <heykal.abdillah@gmail.com>)
List pgsql-hackers
On Thu, May 27, 2010 at 6:56 PM, Mohammad Heykal Abdillah
<heykal.abdillah@gmail.com> wrote:
> On Kam, 2010-05-27 at 15:02 -0400, Robert Haas wrote:
>> On Thu, May 27, 2010 at 1:58 PM, Mohammad Heykal Abdillah
>> <heykal.abdillah@gmail.com> wrote:
>> > Now to the question, why my manualy constructed list was failed to
>> > execute? I was pretty sure that my list node was identical with yacc.
>>
>> Because you have a bug in your code.
>>
> Yes, that i know.
>
> Anyway, this is my manualy generate list node i hope you can point me
> where it went wrong :
> In function "pg_parse_query(const char *query_string)"
>
>  List    *my_parsetree_list;
>  my_parsetree_list = NIL;
>
>  ColumnRef *o = makeNode(ColumnRef);
>                  o->type = T_ColumnRef;
>                  o->fields = list_make1(makeString("*"));
>                  o->location = 16;
>
>  ResTarget *m = makeNode(ResTarget);
>                    m->type = T_ResTarget;
>                    m->name = NIL;
>                    m->indirection = NIL;
>                    m->val = o;
>                    m->location = 16;
>
>  RangeVar *p = makeNode(RangeVar);
>                p->schemaname = NIL;
>                p->relname = "customer";
>      p->inhOpt = 2;
>      p->istemp = false ;
>      p->alias = NIL;
>
>  SelectStmt *n         = makeNode(SelectStmt);
>      n->type           = T_SelectStmt;
>      n->distinctClause = list_make1(NIL);;
>      n->intoClause     = NULL;
>      n->targetList     = list_make1(m);
>      n->fromClause     = list_make1(p);
>      n->whereClause    = NULL;
>      n->groupClause    = NIL;
>      n->havingClause   = NULL;
>      n->valuesLists    = NIL;
>      n->sortClause     = NIL;
>      n->limitOffset    = NULL;
>      n->limitCount     = NULL;
>      n->lockingClause  = NIL;
>      n->op             = 0;
>      n->all            = false;
>      n->larg           = NULL;
>      n->rarg           = NULL;
>
>   my_parsetree_list = list_make1(n);
>
> raw_parsetree_list = my_parsetree_list;
> if (log_parser_stats)
> ShowUsage("PARSER STATISTICS"); ...
> ... and rest its same with original code.

In order to debug this, I (or someone else) would need an actual patch
that could be applied to the source tree with a specific series of
steps that would reproduce the bug.  But I'm not really that
interested in that myself, since this isn't something that is going to
be integrated into the Postgres source code.  If you want to try to
debug it yourself, I suggest using equal() [as Tatsuo-san already
mentioned] or else stepping through the code line by line with a
debugger until you find where it's going wrong, or else adding some
printf() statements to print out key variables in the functions that
are being called and try to find out where the difference is between
the original code and your modified code.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Specification for Trusted PLs?
Next
From: KaiGai Kohei
Date:
Subject: Re: [RFC] Security label support