| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | Ian Lance Taylor <ian(at)airs(dot)com>, Vince Vielhaber <vev(at)michvhf(dot)com>, Justin Clift <justin(at)postgresql(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Re: [PATCHES] Select parser at runtime |
| Date: | 2001-08-13 17:58:36 |
| Message-ID: | 22026.997725516@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Things like VACUUM and ANALYZE, which you will have to keep unless you
> want to implement an Oracle storage manager as well. ;-)
Evidently Ian is just interested in a parser that could be used by
Oracle-compatible applications, which'd not be invoking such operations
anyway. Maintenance scripts would have to use the regular PG parser.
That doesn't seem unreasonable.
Based on his further explanation, it seems that tracking grammar changes
wouldn't be an issue, but tracking parsetree changes definitely would
be. I'm also still concerned about whether this can be done within the
parse step (no database access).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rene Pijlman | 2001-08-13 18:01:24 | Re: JDBC pg_description update needed for CVS tip |
| Previous Message | Peter Eisentraut | 2001-08-13 17:49:38 | Re: Re: [PATCHES] Select parser at runtime |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rene Pijlman | 2001-08-13 18:01:24 | Re: JDBC pg_description update needed for CVS tip |
| Previous Message | Peter Eisentraut | 2001-08-13 17:49:38 | Re: Re: [PATCHES] Select parser at runtime |