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

From Aidan Van Dyk
Subject Re: Patch to fix search_path defencies with pg_bench
Date
Msg-id 20090507164635.GF3305@yugib.highrise.ca
Whole thread Raw
In response to Re: Patch to fix search_path defencies with pg_bench  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Patch to fix search_path defencies with pg_bench  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
* Robert Haas <robertmhaas@gmail.com> [090507 11:15]:
> I bet it would be just as good and a lot simpler to do what someone
> suggested upthread, namely s/^/pgbench_/

That has the "legacy compatibility" problem...

But seeing as "legacy" has a:SET search_path TO public;

And uses plain <table> in it's queries/creates/drops, couldn't we just
make "new" pgbench refer to tables as <schema>.<table> where <schema> is
"public"?  If we leave "schema" as public, and leave in the search_path,
we should be identical to what we currently have, except we've
explicliyt scoped was was searched for before.

And it leads to an easy way for people to change public (in the
search path and/or <schema>.<table>) to do other things (although I'm
not saying that's necessarily required or desired either).

a.

-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Some 8.4 changes needed according to pg_migrator testing
Next
From: Tom Lane
Date:
Subject: Re: Patch to fix search_path defencies with pg_bench