On Mon, Nov 20, 2017 at 7:46 AM, amul sul wrote:
> Thanks for fixing this function. Patch looks good to me, except column number
> in the following errors message should to be 2.
>
> 354 +SELECT satisfies_hash_partition('mchash'::regclass, 2, 1,
> NULL::int, NULL::int);
> 355 +ERROR: column 1 of
On Sat, Nov 18, 2017 at 1:19 AM, Robert Haas wrote:
> On Thu, Nov 16, 2017 at 9:37 AM, amul sul wrote:
>> Fixed in the 001 patch.
>>
>> IMHO, this function is not meant for a user, so that instead of ereport()
>> cant
>> we simply return false? TWIW, I have attached 003 patch which replaces all
On Thu, Nov 16, 2017 at 9:37 AM, amul sul wrote:
> Fixed in the 001 patch.
>
> IMHO, this function is not meant for a user, so that instead of ereport() cant
> we simply return false? TWIW, I have attached 003 patch which replaces all
> erepots() by return false.
I don't think just returning fal
Thanks, Michael & Robert for your suggestions, and apologize for
delayed response
On Tue, Nov 14, 2017 at 6:02 AM, Michael Paquier
wrote:
> On Tue, Nov 14, 2017 at 3:59 AM, Robert Haas wrote:
>> On Mon, Nov 13, 2017 at 3:24 AM, amul sul wrote:
>>> Updated patch attached -- Adjusted code comment
On Tue, Nov 14, 2017 at 3:59 AM, Robert Haas wrote:
> On Mon, Nov 13, 2017 at 3:24 AM, amul sul wrote:
>> Updated patch attached -- Adjusted code comment to survive against pgindent.
>
> That's not the right fix, or at least it's not complete. You
> shouldn't call PG_GETARG_...(n) until you've v
On Mon, Nov 13, 2017 at 3:24 AM, amul sul wrote:
> Updated patch attached -- Adjusted code comment to survive against pgindent.
That's not the right fix, or at least it's not complete. You
shouldn't call PG_GETARG_...(n) until you've verified that
PG_ARGISNULL(n) returns false.
Also, I don't th
