On 1/4/14, 12:00 PM, Tom Lane wrote:
> If you have some settings that need to be table-specific, then
> I agree that the reloptions infrastructure is a nice place to track them.
> What's actually missing here is some compelling examples of such settings
> for plausible extensions.
I've got a real world example.
At work we use limited dumps of production to support development. We do a schema dump and then grab data out of
certain"seed" tables. To mark tables as being seed, we have to store that info in a table, but that gets us into
anotherproblem: what if a table gets renamed?
In order to solve that problem, we created a tables table:
CREATE TABLE tools.tables( id SERIAL PRIMARY KEY, table_schema text, table_name text );
That way if we need to rename a table we update one record in one place instead of a bunch of places (we have other
codethat makes use of tools.tables). (And no, we can't use OIDs because they're not immutable between dumps).
This is obviously ugly and fragile. It'd be much better if we could just define a custom setting on the table itself
thatsays "hey, dump the data from here!". (FWIW, same applies to sequnces).
Actually, I just checked and our seed object stuff doesn't use tools.tables, but our inheritance framework and a change
notificationsystem we wrote does. Those are other examples of where we need to store additional information about a
tableand had to create a system of our own to handle it.
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net
