J.L., * jltal...@adv-solutions.net (jltal...@adv-solutions.net) wrote: > Any suggestions on how to do it "properly"? > Does Greg Stark's suggestion (at > <CAM-w4HPOASwsQMdGZqjyFHNubbUnWrUAo8ibci-97UKU=po...@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
signature.asc
Description: Digital signature