Re: Doing better at HINTing an appropriate column within errorMissingColumn()

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Ian Barwick <ian(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Jim Nasby <jim(at)nasby(dot)net>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
Subject: Re: Doing better at HINTing an appropriate column within errorMissingColumn()
Date: 2014-11-07 20:57:58
Message-ID: CA+TgmoZW_V5ov+ssadU14iJRicJqAdry+4V6+xWU-KVLtCO1tg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 6, 2014 at 3:09 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> On 07/18/2014 10:47 AM, Michael Paquier wrote:
>>
>> On Fri, Jul 18, 2014 at 3:54 AM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
>>>
>>> I am not opposed to moving the contrib code into core in the manner
>>> that you oppose. I don't feel strongly either way.
>>>
>>> I noticed in passing that your revision says this *within* levenshtein.c:
>>>
>>> + * Guaranteed to work with Name datatype's cstrings.
>>> + * For full details see levenshtein.c.
>>
>> Yeah, I looked at what I produced yesterday night again and came
>> across a couple of similar things :) And reworked a couple of things
>> in the version attached, mainly wordsmithing and adding comments here
>> and there, as well as making the naming of the Levenshtein functions
>> in core the same as the ones in fuzzystrmatch 1.0.
>>
>>> I imagined that when a committer picked this up, an executive decision
>>> would be made one way or the other. I am quite willing to revise the
>>> patch to alter this behavior at the request of a committer.
>>
>> Fine for me. I'll move this patch to the next stage then.
>
>
> There are a bunch of compiler warnings:
>
> parse_relation.c: In function ‘errorMissingColumn’:
> parse_relation.c:3114:447: warning: ‘closestcol1’ may be used uninitialized
> in this function [-Wmaybe-uninitialized]
> parse_relation.c:3066:8: note: ‘closestcol1’ was declared here
> parse_relation.c:3129:29: warning: ‘closestcol2’ may be used uninitialized
> in this function [-Wmaybe-uninitialized]
> parse_relation.c:3067:8: note: ‘closestcol2’ was declared here
> levenshtein.c: In function ‘levenshtein_common’:
> levenshtein.c:107:6: warning: unused variable ‘start_column_local’
> [-Wunused-variable]

Based on this review from a month ago, I'm going to mark this Waiting
on Author. If nobody updates the patch in a few days, I'll mark it
Returned with Feedback. Thanks.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2014-11-07 21:00:38 Re: recovery_target_time and standby_mode
Previous Message Alvaro Herrera 2014-11-07 20:55:27 Re: split builtins.h to quote.h