J.L.,
* jltallon@adv-solutions.net (jltallon@adv-solutions.net) wrote:
> Any suggestions on how to do it "properly"?
> Does Greg Stark's suggestion (at
> <CAM-w4HPOASwsQMdGZqjyFHNubbUnWrUAo8ibci-97UKU=poDbg@mail.gmail.com>)
> make sense to you?
> This approach might suffer from the same problem as mine, though.
Well, Greg's suggestion was intended to specifically avoid breaking
pg_dump by having two new GUCs and having default_tablespace take
precedence, if set.
> It seems to me, IMVHO, a limitation in pg_dump ---since 8.0 when
> tablespace support for CREATE INDEX was implemented--- that we
> should fix.
> Keeping backwards compatibility is indeed required; I just did not
> think about pg_dump at all :(
Limitation strikes me as not quite the right term, but I certainly agree
that it's unfortunate that pg_dump uses that GUC instead of adding the
TABLESPACE clause to the CREATE INDEX, then again, there are likely to
be historical reasons for that.
Unfortunately, not break existing pg_dump-generated files is pretty
tough.
> I don't mind reworking the patch or redoing it completely once there
> is a viable solution.
Having three GUCs in the end might work but it seems kind of grotty to
have the more-specific GUCs be overridden by the less-specific GUC.
We could throw a warning if the more-specific GUC is attempted to be set
while the less-specific GUC is set, and vis-versa, and essentially make
them "either/or". That'd cause additional warnings to be thrown when
restoring an older dump, but if pg_dump was modified to use the
TABLESPACE clause for CREATE INDEX for new dump files then that's only a
temporary situation.
Thanks!
Stephen