Skip site navigation (1) Skip section navigation (2)

Re: contrib/snapshot

From: Jim Nasby <jim(at)nasby(dot)net>
To: Joel Jacobson <joel(at)gluefinance(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib/snapshot
Date: 2011-01-03 08:58:26
Message-ID: 7FF28F16-4FB0-437C-ADA9-CC861244B5E8@nasby.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On Jan 2, 2011, at 6:50 PM, Joel Jacobson wrote:
> 2011/1/3 Joel Jacobson <joel(at)gluefinance(dot)com>
> 2011/1/2 Jim Nasby <jim(at)nasby(dot)net>
> Is it actually limited to functions? ISTM this concept would be valuable for anything that's not in pg_class (in other words, anything that doesn't have user data in it).
> 
> Instead of limiting the support to functions, perhaps it would make more sense to limit it to all non-data objects?
> Is there a term for the group of object types not carrying any user data?
> 
> 
> My bad, I see you already answered both my questions.
> So, it does make sense, and the term for non-data object types is therefore non-pg_class, non-class or perhaps non-relation objects?

The generic term for objects that keep their metadata in pg_class is "relation".

Actually, now that I think about it, existence in pg_class isn't a good determining factor, because there's stuff like types in there.

Aside from tables and sequences, you might also want to exclude indexes, or at least provide the option to, since rebuilding them could take a significant amount of time.
--
Jim C. Nasby, Database Architect                   jim(at)nasby(dot)net
512.569.9461 (cell)                         http://jim.nasby.net



In response to

pgsql-hackers by date

Next:From: Jim NasbyDate: 2011-01-03 09:02:25
Subject: Re: page compression
Previous:From: Greg SmithDate: 2011-01-03 08:54:53
Subject: Re: management of large patches

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group