On Wed, Jun 18, 2014 at 4:53 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > Stephen Frost wrote: > > * Tom Lane (tgl@sss.pgh.pa.us) wrote: > > > Stephen Frost <sfrost@snowman.net> writes: > > > > Yes. I'd definitely like to see an ALTER TABLESPACE option, with an > > > > ERROR that lists out all of the non-temporary objects which are found > > > > (and lists any other databases which have objects in those > > > > tablespaces..). That would allow administrators who have existing > > > > notionally temporary-only tablespaces to go clean things up to make them > > > > actually temporary-only. > > > > I would certainly suggest that the first version of the patch not > > > undertake to allow this property to be ALTERed; the cost-benefit > > > ratio isn't there IMO. > > > > I suppose scheduling downtime to do the check manually across all > > databases, then drop and recreate the tablespace, would work. As > > someone who's working with a couple of these cases, it'd be awful nice > > if there was a way PG would handle it for me. > > I wonder if some form of NOT VALID marking could be useful here. Of > course, this is not a constraint. But a mechanism of a similar spirit > seems apropos. It seems reasonable to leave such a thing for future > improvement. >
+1
Then, to summarize Matheus must do:
* use an option instead of change the syntax and catalog to indicate that a tablespace is used to store temp objects
* throw an exception if we try ALTER the option "only_temp_relations"
* add regression tests
* add documentation
And, of course, register to the next open commitfest [1] to get detailed feedback and review.
