Re: keyword list/ecpg
От | Mike Aubury |
---|---|
Тема | Re: keyword list/ecpg |
Дата | |
Msg-id | 200806131457.54786.mike.aubury@aubit.com обсуждение исходный текст |
Ответ на | Re: keyword list/ecpg (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: keyword list/ecpg
Re: keyword list/ecpg Re: keyword list/ecpg |
Список | pgsql-hackers |
> We're almost certainly going to need some kluges of that sort, so as > long as they're not all over the place I won't object. > > But ... I've seen no evidence that those specific examples are needed. > Why wouldn't we copy all the backend rules? And based on Michael's last > comment it's unclear that we need to avoid adding spaces in the > mechanically generated actions, either (which squares with my gut > feeling about SQL syntax). You'll probably need to get into specific > cases before finding out what kluges you need. I think this was more an 'in principle' - if thats route is ok, then I'll start hacking away properly... I was thinking about the copy on/copy off for more the header info (before the %%) - so we can have a really dumb script that just gets told what blocks to copy - and what to ignore.. There will also be some grammer in the original which we'll need to replace with some ecpg specifics - eg adding grammer for the variables etc. Might be easier to just turn 'off' the original rules and have some custom ecpg stuff appended to the generated code.. Theres also another thing that needs to be decided, which is if the generated ecpg grammer should be developer generated (ie. Michael Meskes runs a script and commits the output), or should be generated for each and every source based installation. I personally would stongly favour the script being a tool for ecpg tool developers and not used as part of a normal installation. -- Mike Aubury http://www.aubit.com/ Aubit Computing Ltd is registered in England and Wales, Number: 3112827 Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ
В списке pgsql-hackers по дате отправления: