Pavel Stehule <pavel.steh...@gmail.com> writes:
> 2010/8/6 Tom Lane <t...@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/values
one variadic array element -> parse it the old way
otherwise -> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
