Re:
От | Pavel Stehule |
---|---|
Тема | Re: |
Дата | |
Msg-id | CAFj8pRDJ9DurGUr=SDaf8pXg0V6WiXMWRRUVx=2gthf3AMYb_g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: (Craig Ringer <craig@2ndquadrant.com>) |
Список | pgsql-hackers |
2016-09-12 9:07 GMT+02:00 Craig Ringer <craig@2ndquadrant.com>:
On 12 September 2016 at 14:29, Pavel Stehule <pavel.stehule@gmail.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 (...[@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
В списке pgsql-hackers по дате отправления: