Re: Re: [PATCHES] Select parser at runtime
От | Bruce Momjian |
---|---|
Тема | Re: Re: [PATCHES] Select parser at runtime |
Дата | |
Msg-id | 200108122122.f7CLMZS15398@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [PATCHES] Select parser at runtime (Ian Lance Taylor <ian@airs.com>) |
Список | pgsql-hackers |
> Tom Lane <tgl@sss.pgh.pa.us> writes: > > > Ian Lance Taylor <ian@airs.com> writes: > > > For example: the datatypes have different names; the set of reserved > > > words is different; Oracle uses a weird syntax for outer joins. > > > > Is it really possible to fix these things strictly in the parser > > (ie, without any semantic analysis)? For example, I don't quite see > > how you're going to translate Oracle-style outer joins to SQL standard > > style without figuring out which fields belong to which relations. > > Keep in mind the cardinal rule for the parsing step: Thou Shalt Not > > Do Any Database Access (because the parser must work even in > > transaction-aborted state, else how do we recognize ROLLBACK command?) > > I admit that I haven't sorted out the outer join thing yet. The > others are easy enough. > Another idea is to put the Oracle stuff in gram.y, but use #ifdef or something to mark the Oracle parts, and run gram.y through yacc/bison with the Oracle defines visiable, and another time to create a second parse state machine without Oracle. I think Jan did that for something like that once. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: