Re: Patch to fix search_path defencies with pg_bench

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Patch to fix search_path defencies with pg_bench
Дата
Msg-id 21179.1241716096@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Patch to fix search_path defencies with pg_bench  ("Joshua D. Drake" <jd@commandprompt.com>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Patch to fix search_path defencies with pg_bench
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Serializable Isolation without blocking