Re: Patch to fix search_path defencies with pg_bench - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch to fix search_path defencies with pg_bench
Date
Msg-id 21179.1241716096@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch to fix search_path defencies with pg_bench  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
"Joshua D. Drake" <jd@commandprompt.com> writes:
> On Thu, 2009-05-07 at 12:58 -0400, Aidan Van Dyk wrote:
>> True enough... What about making the prefix be configurable, so by
>> default, it could be "pgbench_", it could be set to "" (to force it to
>> use old pgbench names) or set to "something." to get it to use a
>> different schema (noting that the comparisons to older ones not doing
>> catalog lookups are void).

> Then you have to pass the prefix on the command line. That seems a bit
> over doing it for such a simple utility.

Yes, this seems like vastly more work than is called for.

>> But by dropping the search_path, you're necessarily changing the catalog
>> comparisons and lookups anyways, because your now taking a "random"
>> search path to follow (which could have multiple entries in it) instead
>> of one guaranteed to be a single, useable entry.

> Except that it isn't a guaranteed usable entry, which is why I submitted
> the patch.

I think this argument is bogus anyway.  The tables are always going to be
created in the default creation schema, ie, the first one on the search
path.  As long as you don't change the effective search_path between
pgbench -i and the actual test runs, it won't matter whether that is
public or something else.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Patch to fix search_path defencies with pg_bench
Next
From: Simon Riggs
Date:
Subject: Re: Serializable Isolation without blocking