Add column name to error message?

Em 18/03/2014 17:17, Francisco Olarte escreveu:

Hi:

On Tue, Mar 18, 2014 at 8:22 PM, Edson Richter
<edsonrichter@hotmail.com <mailto:edsonrichter@hotmail.com>> wrote:

Since my table can have more than one "character varying(20)"
inside, would be useful to know which one has throw the error...
Is there any reasoning (security, perhaps) for hiding column name
in the error?

Maybe they are not hiding it, but the error is raised by a value
checking routine which does not know where the value comes from / goes
to ( ie, it's a 'check_varchar(xx, maxlen), which is used to check
columns, function aprameters, type casts....) ( that happens to me in
my own code in some places where the context / error message is
extremely difficult to propagate down / up ) .

Francisco Olarte.

Thanks, Francisco. I don't know internals.
But, doesn't the "value checking routing" caller's know which column is
being tested?

Regards,
--

*Edson Carlos Ericksson Richter*
/Sistemas para Bibliotecas, Escolinhas Infantis
Projetos sob medida para sua empresa/
Celular: (51) 9318-9766
(51) 8585-0796
/"A mente que se abre a uma nova ideia jamais voltará ao seu tamanho
original"/
- Albert Einstein

Edson Richter <edsonrichter@hotmail.com> writes:

Em 18/03/2014 17:17, Francisco Olarte escreveu:

Maybe they are not hiding it, but the error is raised by a value
checking routine which does not know where the value comes from / goes
to ( ie, it's a 'check_varchar(xx, maxlen), which is used to check
columns, function aprameters, type casts....) ( that happens to me in
my own code in some places where the context / error message is
extremely difficult to propagate down / up ) .

Thanks, Francisco. I don't know internals.
But, doesn't the "value checking routing" caller's know which column is
being tested?

No. Typically all it would know is that it's evaluating a targetlist; the
fact that the resulting tuple is going to be inserted into some particular
table is known only at much higher levels (not even the same plan node).

I've thought about using our "errcontext()" mechanism to help with this,
but there's still a lot of additional infrastructure that would be needed
... and that infrastructure would not be without cost. I'm afraid it
would result in measurable slowdowns in query execution. Not sure if
people would think that's a good tradeoff.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Em 18/03/2014 17:44, Tom Lane escreveu:

Edson Richter <edsonrichter@hotmail.com> writes:

Em 18/03/2014 17:17, Francisco Olarte escreveu:

Maybe they are not hiding it, but the error is raised by a value
checking routine which does not know where the value comes from / goes
to ( ie, it's a 'check_varchar(xx, maxlen), which is used to check
columns, function aprameters, type casts....) ( that happens to me in
my own code in some places where the context / error message is
extremely difficult to propagate down / up ) .

Thanks, Francisco. I don't know internals.
But, doesn't the "value checking routing" caller's know which column is
being tested?

No. Typically all it would know is that it's evaluating a targetlist; the
fact that the resulting tuple is going to be inserted into some particular
table is known only at much higher levels (not even the same plan node).

I've thought about using our "errcontext()" mechanism to help with this,
but there's still a lot of additional infrastructure that would be needed
... and that infrastructure would not be without cost. I'm afraid it
would result in measurable slowdowns in query execution. Not sure if
people would think that's a good tradeoff.

regards, tom lane

Thanks, Tom.
I don't know much about Postgres source code. I was wondering if it
works like in Java apps, where the exception thrown is capture by higher
layer until having enough information to provide complete erros message
to the user (being a user a real user or kind of interface - jdbc or
odbc - user).

Now I understand better, and I'm also afraid of getting slowdown. I do
prefer the higher performance at price of having to discover the right
problem on my own.

Regards,

Edson

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general