From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | |
Date: | 2016-09-12 06:29:36 |
Message-ID: | CAFj8pRDqpzyA9d8_nLiZ6=Gw4Mk9=1GByZM7_hHA0ruADYsOiw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2016-09-12 8:14 GMT+02:00 Craig Ringer <craig(at)2ndquadrant(dot)com>:
> On 12 September 2016 at 14:02, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > Hi
> >
> > There is some opened questions - the standard (and some other databases)
> > requires entering XPath expression as string literal.
> >
> > I am thinking so it is too strong not necessary limit - (it enforces
> dynamic
> > query in more cases), so I allowed the expressions there.
>
> I agree. There's no reason not to permit expressions there, and there
> are many other places where we have similar extensions.
>
> > Another questions is when these expressions should be evaluated. There
> are
> > two possibilities - once per query, once per input row. I selected "once
> per
> > input row mode" - it is simpler to implement it, and it is consistent
> with
> > other "similar" generators - see the behave and related discussion to
> > "array_to_string" and evaluation of separator argument. The switch to
> "once
> > per query" should not be hard - but it can be strange for users, because
> > some his volatile expression should be stable.
>
> 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 || ']
My opinion is not too strong - now, what I know, there is not any only once
per query executed expression in Postgres - so this implementation will be
a precedent.
>
> The only use case I see for evaluating them each time is - maybe -
> DEFAULT. Where maybe there's a use for nextval() or other volatile
> functions. But honestly, I think that's better done explicitly in a
> post-pass, i.e.
>
> select uuid_generate_v4(), x.*
> from (
> xmltable(.....) x
> );
>
> in cases where that's what the user actually wants.
>
DEFAULT should be evaluated per output row - anybody can use volatile
function there - example: when I have not data - use some random there
Regards
Pavel
>
> There's no other case I can think of where expressions as arguments to
> set-returning functions are evaluated once per output row.
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2016-09-12 06:30:03 | Re: Re: [COMMITTERS] pgsql: Use LEFT JOINs in some system views in case referenced row doesn |
Previous Message | Craig Ringer | 2016-09-12 06:14:49 | Re: patch: function xmltable |