Re: vpath builds and verbose error messages

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: vpath builds and verbose error messages
Date: 2011-11-18 14:44:53
Message-ID: 15448.1321627493@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Peter Eisentraut's message of vie nov 18 01:34:18 -0300 2011:
>> When using verbose error messages (psql \set VERBOSITY verbose) with a
>> vpath build, you get this sort of thing:
>> LOCATION: transformColumnRef, /build/buildd-postgresql-9.1_9.1.1-3-i386-AP0ovQ/postgresql-9.1-9.1.1/build/../src/backend/parser/parse_expr.c:766
>>
>> Can we shorten that path somehow? Either in the C code when printing it
>> out, or during the build. Any ideas?

> Huh, I hadn't noticed, even though I see those all the time. I agree
> with shortening the path so that it's relative to the root source dir,
> if that's what you propose:

In a non-vpath build you just get the file name (or at least that's what
I'm used to seeing). I agree with Peter that a full path seems a bit
over the top.

It wouldn't be that hard for elog.c to do strrchr(fname, '/') or
something like that, but the idea that there are hundreds of full-path
strings embedded in the executable is a bit annoying. I guess we could
hope that the compiler is bright enough to store it only once per source
file, so the actual space requirement may not be all *that* bad.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-11-18 14:47:18 Re: VACUUM touching file but not updating relation
Previous Message Tom Lane 2011-11-18 14:35:05 Re: Core Extensions relocation