Re: patch: function xmltable

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Craig Ringer <craig@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-01-25T21:40:22Z
Lists: 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


Commits

  1. Support XMLTABLE query expression

  2. Create <sect3> in the functions-xml section

  3. Improve handling of "UPDATE ... SET (column_list) = row_constructor".

  4. Add xmlexists function