From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | Postgres Hackers List <hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Join syntax |
Date: | 1999-09-16 14:09:37 |
Message-ID: | 22127.937490977@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> It's a real pita to flatten the join expressions into the traditional
> Postgres query tree. It would be nice to start thinking about how to
> represent general subqueries or intermediate queries in the parse
> tree.
Yes. Jan has been saying for some time that he needs that for rules.
Also, I have found some squirrely cases in INSERT ... SELECT ... that
can't really be done right unless the INSERT and SELECT targetlists
are kept separate, which seems to mean a two-level parsetree structure.
The UNION/INTERSECT/EXCEPT code has a really klugy approach to
multi-query parse trees, which maybe could be cleaned up if we
supported them in a more general fashion.
Maybe it's time to bite the bullet and do it. You have any thoughts
on what the representation should look like?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Bouska | 1999-09-16 14:16:58 | 1d,1e,1f poison for data? |
Previous Message | Tom Lane | 1999-09-16 13:48:47 | Re: [HACKERS] NOTICE: SIReadEntryData: cache state reset TRAP: Failed Assertion("!(RelationNameCache->hctl->nkeys == 10):", File: "relcache.c", Line: 1458) |