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 another problem: 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 code that 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 that says "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 notification system we wrote does. Those are other examples of where we need to store additional information about a table and had to create a system of our own to handle it. -- Jim C. Nasby, Data Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
