Re: Initial review of xslt with no limits patch

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Initial review of xslt with no limits patch
Дата
Msg-id 7244.1281117402@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Initial review of xslt with no limits patch  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2010/8/6 Tom Lane <tgl@sss.pgh.pa.us>:
>> I think there are issues here that we need to take a step back and think
>> about.  Right now, thanks to the lack of documentation, we can probably
>> assume there are approximately zero users of the xslt_process parameter
>> feature.  Once we document it that'll no longer be true.  So right now
>> would be the time to reflect on whether this is a specification we
>> actually like or believe is usable; it'll be too late to change it
>> later.

> I know about one important user from Czech Republic

Well, if there actually is anybody who's figured it out, we could easily
have a backwards-compatible mode.  Provide one variadic function that
acts as follows:even number of variadic array elements -> they're names/valuesone variadic array element -> parse it
theold wayotherwise -> error
 

I wouldn't even bother with fixing the MAXPARAMS limitation for the
"old way" code, just make it work exactly as before.

> I'll propose a new kind of functions (only position parameter's
> function). My idea is simple - for functions with this mark the mixed
> and named notation is blocked.

We don't need random new function behaviors for this.  Anyway your
proposal doesn't work at all for non-constant parameter names.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Cost of AtEOXact_Buffers in --enable-cassert
Следующее
От: Tom Lane
Дата:
Сообщение: Re: including backend ID in relpath of temp rels - updated patch