Re: "unexpected" query behaviour after i change parser code

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Mohammad Heykal Abdillah <heykal(dot)abdillah(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: "unexpected" query behaviour after i change parser code
Date: 2010-05-23 03:08:02
Message-ID: AANLkTikWGgz1hXzH7mJvd8ay-kFijwqTx7Ee5CCvBVGc@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, May 22, 2010 at 9:33 PM, Mohammad Heykal Abdillah
<heykal(dot)abdillah(at)gmail(dot)com> wrote:
>> > My question :
>> > 1) Can someone explain why my last test it's work?
>>
>> In standard PostgreSQL, "select item from item" is valid SQL.  It
>> returns a single column whose value is a record containing all the
>> columns from the item table.  I suspect something similar is happening
>> in your case.
>>
>
> Hmm.., i know that "select item from item" is valid SQL. But since in my
> case "from cause" was deleted. Shouldnt "select item.id_item,item;"
> failed? Since "select id_item,name;" was also failed.

Well, it's hard for me to speculate about what your code might do. I
think your best bet is to fire up gdb and maybe stick in some
debugging printfs and see if you can figure out what's happening.

>> Which brings me to another point: I'm not really sure what
>> you're trying to accomplish with this modification, considering that
>> adding_missing_from sounds like it does about what you want, but
>> without breaking nearly as much stuff.
>>
>
> I am trying to make some kind automate join relation without have to
> explicitly declare the join relation key.
>
> Example :
> "select item_id,fname;" in my modified query will be eqivalen with SQL
> query.
>
> "select item.id_item,customer.fname from item,fname where
> item.id_item=customer.id"
>
> Ah, yes my "conversion" will be do after raw_parsertree was forming by
> lex and yacc.

It's probably not possible to do this well in general. You might want
to think about writing some kind of preprocessor or query generator
that would rewrite your queries like this for you before sending them
to the database, rather than modifying PostgreSQL itself.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-05-23 03:09:42 Re: Specification for Trusted PLs?
Previous Message Robert Haas 2010-05-23 03:01:57 Re: beta testing - pg_upgrade bug fix - double free