Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group