On Wed, Jun 18, 2014 at 4:53 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > Stephen Frost wrote: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > Stephen Frost <sfr...@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. Regards, [1] https://commitfest.postgresql.org/ -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL >> Timbira: http://www.timbira.com.br >> Blog sobre TI: http://fabriziomello.blogspot.com >> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello >> Twitter: http://twitter.com/fabriziomello
