Re: How about a proper TEMPORARY TABLESPACE?

On Wed, Jun 18, 2014 at 4:53 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:
>
> Stephen Frost wrote:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > > Stephen Frost <sfrost(at)snowman(dot)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