Re: [REVIEW] Patch for cursor calling with named parameters

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: [REVIEW] Patch for cursor calling with named parameters
Дата
Msg-id 4EDC9042020000250004382F@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: [REVIEW] Patch for cursor calling with named parameters  (Yeb Havinga <yebhavinga@gmail.com>)
Ответы Re: [REVIEW] Patch for cursor calling with named parameters  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
Yeb Havinga <yebhavinga@gmail.com> wrote:
> On 2011-12-03 21:53, Kevin Grittner wrote:
>> (1)  Doc changes:
>>
>>    (a) These contain some unnecessary whitespace changes which
>>        make it harder to see exactly what changed.
> 
> This is probably caused because I used emacs's fill-paragraph
> (alt+q)  command, after some changes. If this is against policy, I
> could change the additions in such a way as to cause minor
> differences, however I believe that the benefit of that ends
> immediately after review.
I don't know whether it's a hard policy, but people usually minimize
whitespace changes in such situations, to make it easier for the
reviewer and committer to tell what really changed.  The committer
can always reformat after looking that over, if they feel that's
useful.  The issue is small enough here that I'm not inclined to
consider it a blocker for sending to the committer.
>> (2)  The error for mixing positional and named parameters should
>> be moved up.  That seems more important than "too many arguments"
>> or "provided multiple times" if both are true.
> 
> I moved the error up, though I personally tend to believe it
> doesn't even need to be an error. There is no technical reason not
> to allow it. All the user needs to do is make sure that the
> combination of named parameters and the positional ones together
> are complete and not overlapping. This is also in line with
> calling functions, where mixing named and positional is allowed,
> as long as the positional arguments are first. Personally I have
> no opinion what is best, include the feature or give an error, and
> I removed the possibility during the previous commitfest.
If there's no technical reason not to allow them to be mixed, I
would tend to favor consistency with parameter calling rules.  Doing
otherwise seems like to result in confusion and "bug" reports.
How do others feel?
-Kevin


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: planner fails on HEAD
Следующее
От: Robert Haas
Дата:
Сообщение: Re: cannot read pg_class without having selected a database / is this a bug?