Since no revised patch has been forthcoming and the CommitFest is due
to end shortly, I've marked this "Returned with Feedback". Sherrylyn,
please feel free to update the patch and resubmit to the next
CommitFest.
Will do, Robert, and many thanks to Marko for the feedback. I apologize for
the del
On Sun, Sep 4, 2016 at 7:15 PM, Marko Tiikkaja wrote:
> On 2016-05-09 19:42, Sherrylyn Branchaw wrote:
>>
>> I'm attaching a revised patch; please let me know if there are any other
>> issues before I submit to the commitfest.
>
> I think this is mostly good, but these two should be changed:
>
>
Hi Sherrylyn,
On 2016-05-09 19:42, Sherrylyn Branchaw wrote:
I'm attaching a revised patch; please let me know if there are any other
issues before I submit to the commitfest.
I think this is mostly good, but these two should be changed:
errmsg("unexpected end of string: \"%s\"", state->beg
On Thu, May 12, 2016 at 11:46 AM, Sherrylyn Branchaw
wrote:
> Understood. It's just that Tom had already replied, so I wanted to give him
> first crack at it, if, say, I had grossly misinterpreted his suggestions.
> The guide on submitting a patch advises taking silence as consent within
> reason.
Submitting to the CommitFest is how you make sure that someone looks
at the patch to see if any issues exist. Obviously, if someone
reviews before then, that's great, but you can't count on it.
Understood. It's just that Tom had already replied, so I wanted to give him
first crack at it, if, say,
On Mon, May 9, 2016 at 1:42 PM, Sherrylyn Branchaw wrote:
> I'm attaching a revised patch; please let me know if there are any other
> issues before I submit to the commitfest.
Submitting to the CommitFest is how you make sure that someone looks
at the patch to see if any issues exist. Obviously
Finally returning to this...
> Hm, class 42 is generally meant for SQL-level syntax errors. Are these
> errors not coming from subroutines of hstore_in()? I think our usual
> convention is to use ERRCODE_INVALID_TEXT_REPRESENTATION for complaints
> that a data value does not meet its type's con
Sherrylyn Branchaw writes:
> The hstore module uses elog() to default to ERRCODE_INTERNAL_ERROR
> (SQLSTATE XX000) when the error message reads "Syntax error near '%c' at
> position %d".
Yeah, that is entirely bogus. No user-facing error report should ever
return ERRCODE_INTERNAL_ERROR.
> I pro
The hstore module uses elog() to default to ERRCODE_INTERNAL_ERROR
(SQLSTATE XX000) when the error message reads "Syntax error near '%c' at
position %d".
I propose to switch to ereport() to return ERRCODE_SYNTAX_ERROR (SQLSTATE
42601), on the grounds that it's more transparent. It took me longer t