Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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?

In response to


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group