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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Yeb Havinga" <yebhavinga(at)gmail(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [REVIEW] Patch for cursor calling with named parameters
Date: 2011-12-05 15:34:58
Message-ID: 4EDC9042020000250004382F@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Yeb Havinga <yebhavinga(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-12-05 15:35:37 Re: cannot read pg_class without having selected a database / is this a bug?
Previous Message Tom Lane 2011-12-05 15:30:54 Re: planner fails on HEAD