> that have nothing to do with coercion to a target column type.
>
Yes, it's a neat improvement in any case.
--
Franck Verrot
nderstanding all
the mechanisms that are involved to make that happen.
Franck
--
Franck Verrot
On Sun, Oct 30, 2016 at 12:04 AM, Michael Paquier wrote:
>
> Okay, so I have reworked the patch a bit and finished with the
> attached, adapting the context message to give more information. I
> have noticed as well a bug in the patch: the context callback was set
> before checking if the column u
On Sun, Oct 4, 2015 at 12:23 AM, Andres Freund wrote:
> > On 2015-09-15 12:00:25 +0200, Franck Verrot wrote:
> >> diff --git a/src/backend/parser/parse_target.c
> b/src/backend/parser/parse_target.c
> >> index 1b3fcd6..78f82cd 100644
> >> --- a/src/backend/parse
ten.
>
>
Indeed, the first errdetail() will be overwritten. Here's another try.
Thanks again for looking at my patches!
--
Franck Verrot
0001-Report-column-for-which-type-coercion-fails.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On Wed, Aug 19, 2015 at 11:31 PM, Jeff Janes wrote:
>
> I took this for a test drive, and had some comments.on the user visible
> parts.
> [...]
> But I think these belong as CONTEXT or as DETAIL, not as HINT. The
> messages are giving me details about where (which column) the error
> occurred,
On Wed, Jul 1, 2015 at 12:30 AM, Tom Lane wrote:
>
> What seems more likely to lead to a usable patch is to arrange for the
> extra information you want to be emitted as error "context", via an error
> context callback that gets installed at the right times. ...
> ...
> with no need for int8in to
clear how to do that in our system
> structure.
Given my very restricted knowledge of PG's codebase I am not sure whether my
modifications are legitimate or not, so please don't hesitate to comment on
it and pointing where things are subpar to PG's codebase. In any case, it&#x
