On Mon, Oct 7, 2013 at 9:32 AM, Andres Freund <and...@2ndquadrant.com> wrote: >> - RelationIsDoingTimetravel is still a crappy name. How about >> RelationRequiredForLogicalDecoding? And maybe the reloption >> treat_as_catalog_table can become required_for_logical_decoding. > > Hm. I don't really like the name, required seems to imply that it's > necessary to turn this on to get data replicated in that relation. How > about "accessible_during_logical_decoding" or "user_catalog_table"? The > latter would allow us to use it to add checks for user relations used in > indexes which need a treatment similar to enums.
user_catalog_table is a pretty good description, but should we worry about the fact that logical replication isn't mentioned in there anywhere? In what way do you feel that it's more clear to say *accessible during* rather than *required for* logical decoding? I was trying to make the naming consistent; i.e. if we have RelationRequiredForLogicalDecoding then name the option to match. >> All in all, it seems to me that we shouldn't try to punt. Maybe we >> should have something that works like ALTER TABLE name CLUSTER ON >> index_name to configure which index should be used for logical >> replication. Possibly this same syntax could be used as ALTER >> MATERIALIZED VIEW to set the candidate key for that case. > > How about using the current logic by default but allow to tune it > additionally with an option like that? I'm OK with defaulting to the primary key if there is one, but I think that no other candidate key should be entertained unless the user configures it. I think the behavior we get without that will be just too weird. We could use the same logic you're proposing here for CLUSTER, too, but we don't; that's because we've (IMHO, rightly) decided that the choice of index is too important to be left to chance. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers