Re: small regression adjustment

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: small regression adjustment
Date: 2014-03-26 16:47:25
Message-ID: 5333049D.1070900@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 03/26/2014 11:37 AM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> It occurred to me after having to change I think 9 files to clean up a
>> small mess in the jsonb regression tests the other day that we might
>> usefully expose the inputdir and outputdir to psql as variables when
>> running pg_regress. Then we might be able to do thing like this, quite
>> independent of location:
>> \set datafile :inputdir/data/mystuff.data
>> COPY mytable FROM :'datafile';
> If we could get rid of the run-time-generated-test-file facility
> altogether, I could get excited about this; but just getting rid of
> the COPY special cases isn't enough for that. Looking at
> convert_sourcefiles_in, it seems like we'd also need solutions for
> these dynamic substitutions:
>
> replace_string(line, "@testtablespace@", testtablespace);
> replace_string(line, "@libdir@", dlpath);
> replace_string(line, "@DLSUFFIX@", DLSUFFIX);
>
> At least this one seems rather difficult to fix in this fashion:
>
> output/create_function_1.source:83:ERROR: could not find function "nosuchsymbol" in file "@libdir@/regress(at)DLSUFFIX@"
>
> (I'm a bit inclined to think that we could dispense with @DLSUFFIX@
> altogether; explicit use of the platform's library suffix has been
> deprecated for at least a decade. But the others are harder.)
>
>

Well, maybe we should change dfmgr.c to stop outputting the DLSUFFIX in
its error message.

I haven't tried with the other two. I will when I get a spare moment.

But even if we find it too troublesome to get rid if the substitution
part altogether, I think minimizing the need for it would still be worth
doing. It would help extension authors, for example, who are most likely
to want to use it to load data files for testing their extensions.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-03-26 16:49:41 Re: Missing pfree in logical_heap_rewrite_flush_mappings()
Previous Message Ants Aasma 2014-03-26 16:29:38 Missing pfree in logical_heap_rewrite_flush_mappings()