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
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 |