On Mon, Mar 3, 2014 at 3:38 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-02-28 20:55:20 +0530, Amit Kapila wrote:
>> On Thu, Feb 27, 2014 at 4:14 PM, Christian Kruse
>> > Well, as I already stated: we don't. I copied the behavior we use in
>> > CHECK constraints (ExecBuildSlotValueDescription()).
>>
>> I think now more people are of opinion that displaying whole tuple is
>> not useful. I believe it is good to go ahead by displaying just primary key
>> for this case and move ahead.
>
> The patch does not, and has never, printed the full tuple. What it does
> is copying the behaviour of printing the tuple for check constraint
> violations, which is truncating the tuple after a certain length.
I know that patch truncates the values if they are greater than certain
length (30), but the point is why it is not sufficient to have tuple location
(and primary key if available) which uniquely identifies any tuple?
I understand that by displaying more data from tuple, you can locate the
tuple more easily, but still adding more information than required doesn't
seem to advisable.
One more thing, I have noticed that in ExecConstraints() where we are
using ExecBuildSlotValueDescription() to display tuple values doesn't
use tuple location, which we are using in current message, so shouldn't
that be sufficient reason not to display whole tuple in current case?
> I don't think changing this in an isolated manner to the primary key
> would be a good idea. Let's use the same logic here, and if somebody
> wants to argue for always using the primary key instead of a truncated
> tuple, let them submit a separate patch.
I am not sure if we can say that this is an isolated way, as we are already
displaying just tuple location for other cases where we take Exclusive
Lock on tuple, for example:
"LOG: process 3012 still waiting for ExclusiveLock on tuple (0,1) of
relation 57499 of database 12045 after 1014.000 ms".
Even if we display all (truncated) column values for current case,
do you intend to display such information for above message as
well, otherwise we might improve the situation for one case but not
for other.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com