Hi,
Tom Lane <tgl@sss.pgh.pa.us> writes:
> As I work through the extensions patch, the aspect of it that I like the
> least is the NO USER DATA clause and related functions. I think it's
> badly designed, badly implemented, and doesn't solve the problem.
I'm not loving it either, but wanting to stay general enough, then
that's all I came up with.
> After a bit of thought I believe that we can fix this if we are willing
> to teach pg_dump explicitly about extension configuration tables.
Ok, if we're now talking about tables only (which makes a lot of sense,
but somehow I didn't want to restrict it that way).…
> SELECT pg_extension_partial_dump('my_table', 'WHERE NOT system_data');
>
> I'm envisioning that this function would add that information to the
> pg_extension entry, and then pg_dump would use it to select out a subset
> of rows that it would dump as user data, even though it's not dumping
> the table definition.
…then what about taking it the extra mile and have something even more
simple and easier to check and control?
From your idea, where I get is that we could force the system_data
column name and type. We're talking about only supporting tables, and a
boolean expression is all we will be able to use. Then, if the column
name and type are fixed, we only need the non-qualified relation name.
I'd expect that in the control file, so that we don't have to provide
new SQL level tools.
People that need a complex boolean expression will be able to maintain
the column from a trigger.
If we get there, then all we get to store is an oidvector column in the
catalog, the list of the table OIDs we will have to only dump the
content of those rows WHERE NOT system_data.
Or do you want to keep some generality here?
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support