Re: [HACKERS] patch: function xmltable
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] patch: function xmltable |
Дата | |
Msg-id | 20170125214022.sdpoh2lollull2yw@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] patch: function xmltable (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: [HACKERS] patch: function xmltable
|
Список | pgsql-hackers |
Hi, > > > I'll try to explain my motivation. Please, check it and correct me if I > > am > > > wrong. I don't keep on my implementation - just try to implement XMLTABLE > > > be consistent with another behave and be used all time without any > > > surprise. > > > > > > 1. Any function that produces a content can be used in target list. We > > > support SRF in target list and in FROM part. Why XMLTABLE should be a > > > exception? > > > > targetlist SRFs were a big mistake. They cause a fair number of problems > > code-wise. They permeated for a long while into bits of both planner and > > executor, where they really shouldn't belong. Even after the recent > > changes there's a fair amount of uglyness associated with them. We > > can't remove tSRFs for backward compatibility reasons, but that's not > > true for XMLTABLE > > > > > > > ok > > I afraid when I cannot to reuse a SRF infrastructure, I have to reimplement > it partially :( - mainly for usage in "ROWS FROM ()" Huh? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: