Re: PATCH: default_index_tablespace

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: jltallon(at)adv-solutions(dot)net
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PATCH: default_index_tablespace
Date: 2015-04-26 18:28:51
Message-ID: 20150426182851.GE30322@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2015-04-26 18:35:10 Re: INSERT ... ON CONFLICT syntax issues
Previous Message Peter Geoghegan 2015-04-26 18:19:23 Re: INSERT ... ON CONFLICT syntax issues