Re: [REVIEW] Patch for cursor calling with named parameters - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: [REVIEW] Patch for cursor calling with named parameters
Date
Msg-id 4EDC9042020000250004382F@gw.wicourts.gov
Whole thread Raw
In response to Re: [REVIEW] Patch for cursor calling with named parameters  (Yeb Havinga <yebhavinga@gmail.com>)
Responses Re: [REVIEW] Patch for cursor calling with named parameters
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: planner fails on HEAD
Next
From: Robert Haas
Date:
Subject: Re: cannot read pg_class without having selected a database / is this a bug?