On Thu, Feb 01, 2018 at 02:03:23PM -0500, Robert Haas wrote:
> I think it's a shame that the commit message didn't document (for the
> release notes) exactly which cases just got changed incompatibly. I
> admit that not many people are likely to get bitten by this, but I
> still think it's better
On Fri, Jan 26, 2018 at 6:36 PM, Tom Lane wrote:
> I've pushed this mostly as-is. I fixed the missed places in reloptions
> code as we discussed. I also took out the parser changes related to
> allowing unquoted PARALLEL in old-style CREATE AGGREGATE, because that
> is not a goal I consider wort
On Fri, Jan 26, 2018 at 05:58:48PM -0500, Tom Lane wrote:
> Daniel Gustafsson writes:
>> Oversight, completely missed that one.
>
> It looks like no core code uses that macro, so it's got no effect
> unless some third-party code does ... but I changed it anyway.
Good point. I missed this one as
> On 27 Jan 2018, at 00:36, Tom Lane wrote:
>
> I've pushed this mostly as-is.
Thanks!
> I also took out the parser changes related to
> allowing unquoted PARALLEL in old-style CREATE AGGREGATE, because that
> is not a goal I consider worthy of adding extra grammar complexity.
> We don't docu
I've pushed this mostly as-is. I fixed the missed places in reloptions
code as we discussed. I also took out the parser changes related to
allowing unquoted PARALLEL in old-style CREATE AGGREGATE, because that
is not a goal I consider worthy of adding extra grammar complexity.
We don't document t
> On 26 Jan 2018, at 23:58, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 26 Jan 2018, at 22:32, Tom Lane wrote:
>>> I notice that there are two reloptions-related
>>> "pg_strncasecmp" calls that did not get converted to "strncmp":
>>> reloptions.c:804
>
>> The way I read transformRelOp
Daniel Gustafsson writes:
>> On 26 Jan 2018, at 22:32, Tom Lane wrote:
>> I notice that there are two reloptions-related
>> "pg_strncasecmp" calls that did not get converted to "strncmp":
>> reloptions.c:804
> The way I read transformRelOptions(), oldOptions is not guaranteed to
> come from the
> On 26 Jan 2018, at 22:32, Tom Lane wrote:
>
> Michael Paquier writes:
>> On Wed, Jan 24, 2018 at 09:47:50AM +0100, Daniel Gustafsson wrote:
>>> Attached is a rebased v7 patch which has your amendments (minus
>>> propname) which passes make check without errors.
>
>> Confirmed. I am switching
Michael Paquier writes:
> On Wed, Jan 24, 2018 at 09:47:50AM +0100, Daniel Gustafsson wrote:
>> Attached is a rebased v7 patch which has your amendments (minus
>> propname) which passes make check without errors.
> Confirmed. I am switching the status as ready for committer for
> volatility-v7.pa
On Wed, Jan 24, 2018 at 09:47:50AM +0100, Daniel Gustafsson wrote:
> Attached is a rebased v7 patch which has your amendments (minus
> propname) which passes make check without errors.
Confirmed. I am switching the status as ready for committer for
volatility-v7.patch then.
> The volatility patch
> On 24 Jan 2018, at 02:37, Michael Paquier wrote:
> On Tue, Jan 23, 2018 at 04:22:22PM +0100, Daniel Gustafsson wrote:
>> On 23 Jan 2018, at 05:52, Michael Paquier wrote:
>>> Those are changed as well in the attached, which applies on top of your
>>> v6. I have added as well in it the tests I s
On Tue, Jan 23, 2018 at 04:22:22PM +0100, Daniel Gustafsson wrote:
> On 23 Jan 2018, at 05:52, Michael Paquier wrote:
>> 2) indexam.sgml mentions using pg_strcasecmp() for consistency with the
>> core code when defining amproperty for an index AM. Well, with this
>> patch I think that for consiste
> On 23 Jan 2018, at 05:52, Michael Paquier wrote:
>
> On Mon, Jan 22, 2018 at 12:48:45PM +0100, Daniel Gustafsson wrote:
>
>> Not sure how much they’re worth in "make check” though as it’s quite
>> easy to add a new option checked with pg_strcasecmp which then isn’t
>> tested. Still, it might a
On Mon, Jan 22, 2018 at 12:48:45PM +0100, Daniel Gustafsson wrote:
> Gotcha. Iâve added some tests to the patch. The test for CREATE
> FUNCTION was omitted for now awaiting the outcome of the discussion
> around isStrict and isCachable.
That makes sense.
> Not sure how much theyâre worth in
> On 15 Jan 2018, at 02:33, Michael Paquier wrote:
> On Fri, Jan 12, 2018 at 11:35:48PM +0100, Daniel Gustafsson wrote:
>> On 11 Jan 2018, at 09:01, Michael Paquier wrote:
One open question from this excercise is how to write a good test for
this. It can either be made part of the alr
On Fri, Jan 12, 2018 at 11:35:48PM +0100, Daniel Gustafsson wrote:
> On 11 Jan 2018, at 09:01, Michael Paquier wrote:
>> I would like to think that a special section
>> dedicated to option compatibility for each command would be welcome to
>> track which grammar is supported and which grammar is n
> On 11 Jan 2018, at 09:01, Michael Paquier wrote:
>
> On Wed, Jan 10, 2018 at 11:49:47PM +0100, Daniel Gustafsson wrote:
>>> On 08 Jan 2018, at 17:27, Robert Haas wrote:
>>> nor has anyone taken the trouble to list with precision all of the
>>> places where the behavior will change. I think th
On Wed, Jan 10, 2018 at 11:49:47PM +0100, Daniel Gustafsson wrote:
>> On 08 Jan 2018, at 17:27, Robert Haas wrote:
>> nor has anyone taken the trouble to list with precision all of the
>> places where the behavior will change. I think the latter is
>> absolutely indispensable,
>
> I had a look a
> On 08 Jan 2018, at 17:27, Robert Haas wrote:
>
> On Sat, Jan 6, 2018 at 7:38 PM, Tom Lane wrote:
>> It's definitely concerning that the submitted patch introduced a new bug,
>> but we have seldom taken the position that bugs in an initial submission
>> are sufficient grounds for rejecting the
On Sat, Jan 6, 2018 at 7:38 PM, Tom Lane wrote:
> It's definitely concerning that the submitted patch introduced a new bug,
> but we have seldom taken the position that bugs in an initial submission
> are sufficient grounds for rejecting the entire concept.
Fair point. I withdraw my categorical
On Sun, Jan 7, 2018 at 9:38 AM, Tom Lane wrote:
> ISTM that if this patch gets rid of a large fraction of the uses of
> pg_strcasecmp in the backend, which is what I expect it should, then
> it might not be out of reach to go through all the surviving ones to
> make sure they are not processing st
Stephen Frost writes:
> Thinking through it, for my own 2c on this, I tend to agree with Tom
> that, really, we should be using strcmp() for anything coming out of the
> parser and that the backward-compatibility break from that is
> acceptable. I also understand Robert's concern that there may b
Greetings Michael, Daniel, all,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Fri, Dec 1, 2017 at 4:14 AM, Robert Haas wrote:
> > I think the changes in DefineView and ATExecSetRelOptions is wrong,
> > because transformRelOptions() is still using pg_strcasecmp. With the
> > patch:
>
On Fri, Dec 1, 2017 at 4:14 AM, Robert Haas wrote:
> I think the changes in DefineView and ATExecSetRelOptions is wrong,
> because transformRelOptions() is still using pg_strcasecmp. With the
> patch:
>
> rhaas=# create view v(x) with ("Check_option"="local") as select 1;
> CREATE VIEW
> rhaas=#
On Thu, Nov 30, 2017 at 6:40 AM, Daniel Gustafsson wrote:
> For reasons unknown to me I had avoided poking in contrib/. Attached patch
> handles the additional defname comparisons in contrib that are applicable.
I am having a bit of trouble understanding why the first hunk in
DefineAggregate() i
> On 28 Nov 2017, at 02:07, Michael Paquier wrote:
>
> On Tue, Nov 28, 2017 at 12:11 AM, Daniel Gustafsson wrote:
>>> The patch needs a rebase, and there are a couple of places that need
>>> an extra lookup I think:
>>> $ git grep defname -- *.c | grep strcasecmp | wc -l
>>> 39
>>
>> Rebase
On Thu, Nov 30, 2017 at 7:40 AM, Daniel Gustafsson wrote:
>> On 29 Nov 2017, at 04:29, Michael Paquier wrote:
>>
>> On Tue, Nov 28, 2017 at 10:07 AM, Michael Paquier
>> wrote:
>>> I was just looking at the tsearch code which uses pg_strcmpcase, and
>>> those are defined with makeDefElem() so you
> On 29 Nov 2017, at 04:29, Michael Paquier wrote:
>
> On Tue, Nov 28, 2017 at 10:07 AM, Michael Paquier
> wrote:
>> I was just looking at the tsearch code which uses pg_strcmpcase, and
>> those are defined with makeDefElem() so you should switch to strcmp in
>> this case as well, no? If I patch
On Tue, Nov 28, 2017 at 10:07 AM, Michael Paquier
wrote:
> I was just looking at the tsearch code which uses pg_strcmpcase, and
> those are defined with makeDefElem() so you should switch to strcmp in
> this case as well, no? If I patch the code myself I would get an error
> when double-quoting, m
On Tue, Nov 28, 2017 at 12:11 AM, Daniel Gustafsson wrote:
>> The patch needs a rebase, and there are a couple of places that need
>> an extra lookup I think:
>> $ git grep defname -- *.c | grep strcasecmp | wc -l
>> 39
>
> Rebased and handled a few more places which I had either missed in th
> On 17 Nov 2017, at 03:31, Michael Paquier wrote:
>
> On Tue, Sep 5, 2017 at 5:34 PM, Daniel Gustafsson wrote:
>>> On 17 Aug 2017, at 11:08, Daniel Gustafsson wrote:
On 16 Aug 2017, at 17:51, Tom Lane wrote:
My thought is that if we are looking at words that have been through the
>>
On Tue, Sep 5, 2017 at 5:34 PM, Daniel Gustafsson wrote:
>> On 17 Aug 2017, at 11:08, Daniel Gustafsson wrote:
>>> On 16 Aug 2017, at 17:51, Tom Lane wrote:
>>> My thought is that if we are looking at words that have been through the
>>> parser, then it should *always* be plain strcmp; we should
32 matches
Mail list logo
