On Mon, Nov 7, 2016 at 10:26 AM, Franck Verrot wrote:
>
>
> On Sun, Nov 6, 2016 at 1:13 PM, Tom Lane wrote:
>>
>> > The original intent of that patch tried to cover the case where we
>> > insert
>> > records
>> > made of dozens columns sharing the same type definition, and trying to
>> > understa
On Sun, Nov 6, 2016 at 1:13 PM, Tom Lane wrote:
>
> > The original intent of that patch tried to cover the case where we insert
> > records
> > made of dozens columns sharing the same type definition, and trying to
> > understand
> > what is going on, at a glance, when we debugged something like t
Franck Verrot writes:
> On Sat, Nov 5, 2016 at 11:13 AM, Tom Lane wrote:
>> The cases that are successfully annotated by the current patch seem to
>> mostly already have error cursor information, which really is good enough
>> IMO --- you can certainly figure out which column corresponds to the
>
On Sat, Nov 5, 2016 at 11:13 AM, Tom Lane wrote:
>
> The cases that are successfully annotated by the current patch seem to
> mostly already have error cursor information, which really is good enough
> IMO --- you can certainly figure out which column corresponds to the
> textual spot that the cur
I wrote:
> ... I wonder whether we should
> not try to move in the direction of expanding the set of errors that we
> can provide error cursor info for. One aspect of that would be making
> sure that the text of the current statement is always available at
> runtime. I believe we do always have i
I wrote:
> Maybe it'd be all right to commit this anyway, but I'm afraid the most
> common reaction would be "why's it give me this info some of the time,
> but not when I really need it?" I'm inclined to think that an acceptable
> patch will need to provide context for the plan-time and run-time
On Sat, Nov 5, 2016 at 4:15 AM, Tom Lane wrote:
> The callback is "live" the instant you assign to error_context_stack;
> any data it depends on had better be valid before that. In this case
> you're effectively depending on the assumption that
> RelationGetRelationName can't throw an error.
Arg
On Fri, Nov 4, 2016 at 12:15 PM, Tom Lane wrote:
> Michael Paquier writes:
> > I am passing that down to a committer for review. The patch looks
> > large, but at 95% it involves diffs in the regression tests,
> > alternative outputs taking a large role in the bloat.
>
> This is kind of cute, bu
Michael Paquier writes:
> I am passing that down to a committer for review. The patch looks
> large, but at 95% it involves diffs in the regression tests,
> alternative outputs taking a large role in the bloat.
This is kind of cute, but it doesn't seem to cover very much territory,
because it onl
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 Mon, Oct 17, 2016 at 12:48 PM, Michael Paquier
wrote:
> *** /Users/mpaquier/git/postgres/src/test/regress/expected/xml_2.out
> Mon Oct 17 11:32:26 2016
> --- /Users/mpaquier/git/postgres/src/test/regress/results/xml.out
> Mon Oct 17 15:58:42 2016
> ***
> *** 9,14
> --- 9,15
On Wed, Oct 19, 2016 at 3:14 AM, Robert Haas wrote:
> On Mon, Oct 17, 2016 at 3:18 AM, Michael Paquier
> wrote:
>> Andres wrote:
>>> +/* Support for TransformExprCallback */
>>> +typedef struct TransformExprState
>>> +{
>>> + const char *column_name;
>>> + Oid expected_type;
>>> +} Transf
On Mon, Oct 17, 2016 at 3:18 AM, Michael Paquier
wrote:
> Andres wrote:
>> +/* Support for TransformExprCallback */
>> +typedef struct TransformExprState
>> +{
>> + const char *column_name;
>> + Oid expected_type;
>> +} TransformExprState;
>> I see no need for this to be a struct defined i
On Thu, Oct 6, 2016 at 2:58 PM, Franck Verrot wrote:
> Michael, please find attached a revised patch addressing, amongst some other
> changes, the testing issue (`make check` passes now) and the visibility of
> the ` TransformExprState` struct.
+ /* Set up callback to identify error line number
Thanks Andres for the review.
Michael, please find attached a revised patch addressing, amongst some
other changes, the testing issue (`make check` passes now) and the
visibility of the ` TransformExprState` struct.
Thanks,
Franck
On Tue, Dec 22, 2015 at 1:49 PM, Michael Paquier
wrote:
> On Su
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/parser/parse_target.c
>> +++ b/src/backend/pars
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/parser/parse_target.c
> +++ b/src/backend/parser/parse_target.c
> @@ -389,6 +389,17 @@ markTargetListOrigin(
On Tue, Sep 15, 2015 at 7:12 AM, Alvaro Herrera
wrote:
>
> I think you need errcontext(), not errdetail(). The most important
> difference is that you can have multiple CONTEXT lines but only one
> DETAIL; I think if you attach a second errdetail(), the first one is
> overwritten.
>
>
Indeed, the
Franck Verrot wrote:
> 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 (wh
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,
Jeff Janes writes:
> The hints you add end in a new line, which then gives two new lines once
> they are emitted. This is contrary to how other HINTs are formatted.
> Other HINTs are complete sentences (start with a capital letter, end with a
> period).
> But I think these belong as CONTEXT or as
On Sun, Aug 9, 2015 at 8:44 AM, Franck Verrot wrote:
> 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 installe
On Sun, Aug 9, 2015 at 11:44 AM, Franck Verrot wrote:
> 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 a
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
Franck Verrot writes:
> As far as I know, there is currently no way to find which column is triggering
> an error on an INSERT or ALTER COLUMN statement. Example:
Indeed ...
> Given my very restricted knowledge of PG's codebase I am not sure whether my
> modifications are legitimate or not, so p
Hi all,
As far as I know, there is currently no way to find which column is triggering
an error on an INSERT or ALTER COLUMN statement. Example:
# create table foo(bar varchar(4), baz varchar(2));
CREATE TABLE
# insert into foo values ('foo!', 'ok');
INSERT 0 1
# insert into f
26 matches
Mail list logo
