Re: PATCH: default_index_tablespace

J.L.,

* jltallon(at)adv-solutions(dot)net (jltallon(at)adv-solutions(dot)net) wrote:
> Any suggestions on how to do it "properly"?
> Does Greg Stark's suggestion (at
> <CAM-w4HPOASwsQMdGZqjyFHNubbUnWrUAo8ibci-97UKU=poDbg(at)mail(dot)gmail(dot)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