Re:

2016-09-12 9:07 GMT+02:00 Craig Ringer <craig(at)2ndquadrant(dot)com>:

> On 12 September 2016 at 14:29, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
> >> I would've expected once per query. There's no way the expressions can
> >> reference the row data, so there's no reason to evaluate them each
> >> time.
> >
> > I disagree - it is hypothetical situation but it is possible
> >
> > if somebody store documents like
> >
> > id, xml
> > =====
> > id = 1, xml = <doc id = 1> ....<>
> > id = 2, xml = <doc id = 2> ....
> >
> > Then evaluating one per query doesn't allow to use any reference to other
> > columns, and doesn't to build expressions like PATH ((dot)(dot)(dot)[(at)id= ' || id ||
> ']
>
> Referencing columns on the same evaluation level? I dunno about that.
> You're relying on strict order of evaluation which is pretty unusual
> for SQL.
>
> I guess this is why full XQuery would be desirable, but that's a whole
> different business.
>
> I would personally expect this sort of thing to be handled by a second
> pass; isn't that part of why it's so easy to return xml fields from
> xmltable?
>
> Evaluating expressions each time seems likely to be bad for
> performance, but I guess it's not going to make a big difference
> compared to all the XML crud, so I don't have a super strong opinion
> here.
>

When expression will a constant, then the cost will be minimal - more, we
can do preevaluation in parser/transform time, and if expression is some
constant, then we should not to evaluate it later.

We can wait if some other people will have a opinion to this topic. This is
important topic, but it is not to hard implement both variants, and more -
this is corner case - it is not important for any example that I found on
net.

Regards

Pavel

>
> Either way, it's crucial that the behaviour be documented.
>
> > DEFAULT should be evaluated per output row - anybody can use volatile
> > function there - example: when I have not data - use some random there
>
> That would be consistent with how we handle DEFAULT on a table, so I
> agree. It's a departure from what we do normally, but we didn't have
> table functions before either.
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>