Re: patch for 9.2: enhanced errors

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Steve Singer <ssinger_pg(at)sympatico(dot)ca>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch for 9.2: enhanced errors
Date: 2011-06-19 10:51:13
Message-ID: BANLkTinpzq5TBU_iTEVzaJ=Kq-jTyFghzg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello

2011/6/19 Steve Singer <ssinger_pg(at)sympatico(dot)ca>:
> On 11-06-08 04:14 PM, Pavel Stehule wrote:
>>
>> Hello
>>
>> Attached patch implements a new erros's fields that describes table,
>> colums related to error. This enhanced info is limited to constraints
>> and RI.
>>
>
...
>
> I think that both the CONSTRAINT, and TABLE name should be double quoted
> like "A_pkey" is above.  When doing this make sure you don't break the
> quoting in the CSV format log.
>

I agree so quoting must be used in CSV log - the result have to be
valid CSV and I'll ensure this. I am not sure about implicit quoting
and using some quote_ident operation early. This is result of some
operation - not input. Quoting in message is used not like SQL
quoting, but as plain text quoting - it is just border between human
readable text and data. But fields like TABLE_NAME or COLUMN_NAME
contains just data - so quoting is useless.

Next argument - the quoting is more simple than remove quoting. If
somebody needs to quoting, then can use a quoting_ident function, but
there are no inverse function - so I prefer a names in raw format. It
is more simply and usual to add quoting than remove quoting.

What do you think about?

>
> Performance Review
> -----------------------------
> I don't see this patch impacting performance, I did not conduct any
> performance tests.
>
>
> Coding Review
> -----------------
>
>
> In tupdesc.c
>
> line 202 the existing code is performing a deep copy of ConstrCheck.  Do you
> need to copy nkeys and conkey here as well?
>
> Then at line 250 ccname is freed but not conkey
>

I have to look on this

>
> postgres_ext.h line 55
> + #define PG_DIAG_SCHEMA_NAME    's'
> + #define PG_DIAG_TABLE_NAME    't'
> + #define PG_DIAG_COLUMN_NAMES    'c'
> + #define PG_DIAG_CONSTRAINT_NAME 'n'
>
> The assignment of letters to parameters seems arbitrary to me, I don't have
> a different non-arbitrary mapping in mind but if anyone else does they
> should speak up.  I think it will be difficult to change this after 9.2 goes
> out.
>
>
> elog.c:
> ***************
> *** 2197,2202 ****
> --- 2299,2319 ----
>      if (application_name)
>          appendCSVLiteral(&buf, application_name);
>
> +     /* constraint_name */
> +     appendCSVLiteral(&buf, edata->constraint_name);
> +     appendStringInfoChar(&buf, ',');
> +
> +     /* schema name */
> +     appendCSVLiteral(&buf, edata->schema_name);
> +     appendStringInfoChar(&buf, ',');
>
> You need to update config.sgml at the same time you update this format.
> You need to append a "," after application name but before constraintName.
> As it stands the CSV log has something like:
> .....nbtinsert.c:433","psql""a_pkey","public","a","a"
>

ok

>
> nbtinsert.c
>
> pg_get_indrelation is named differently than everything else in this file
> (ie _bt...).  My guess is that this function belongs somewhere else but I
> don't know the code well enough to say where you should move it too.
>

I'll try to get better name, but I would not use a public name like _bt

>
>
> Everything I've mentioned above is a minor issue, I will move the patch to
> 'waiting for author' and wait for you to release an updated patch.
>
> Steve Singer
>

ok

Thank you very much

Pavel Stehule

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2011-06-19 10:53:14 Re: patch for 9.2: enhanced errors
Previous Message Radosław Smogura 2011-06-19 10:46:17 Re: Hugetables question