At Thu, 29 Jun 2023 13:56:38 -0700, Nathan Bossart <nathandboss...@gmail.com> wrote in > Thanks for taking a look. > > On Thu, Jun 29, 2023 at 02:16:26PM +0900, Kyotaro Horiguchi wrote: > > At Wed, 28 Jun 2023 16:24:02 -0700, Nathan Bossart > > <nathandboss...@gmail.com> wrote in > >> I debated also allowing users to specify different types of objects in the > >> same command (e.g., "vacuumdb --schema myschema --table mytable"), but it > >> looked like this would require a more substantial rewrite, and I didn't > >> feel that the behavior was intuitive. For the example I just gave, does > >> the user expect us to process both the "myschema" schema and the "mytable" > >> table, or does the user want us to process the "mytable" table in the > >> "myschema" schema? In vacuumdb, this is already blocked, but reindexdb > > > > I think spcyfying the two at once is inconsistent if we maintain the > > current behavior of those options. > > > > It seems to me that that change clearly modifies the functionality of > > the options. As a result, those options look like restriction > > filters. For example, "vacuumdb -s s1_* -t t1" will vacuum all table > > named "t1" in all schemas matches "s1_*". > > Sorry, I'm not following. I intentionally avoided allowing combinations of > --schema and --table in the patches I sent. This is the current behavior > of vacuumdb. Are you suggesting that they should be treated as restriction > filters?
No. I'm not suggesting. Just saying that they would look appear to work as a restriction filters if those two options can be specified at once. > > While I think this is useful, primarily for system catalogs, I'm not > > entirely convinced about its practicality to user objects. It's > > difficult for me to imagine that a situation where all databases share > > the same schema would be major. > > > > Assuming this is used for user objects, it may be necessary to safely > > exclude databases that lack the specified schema or table, provided > > the object present in at least one other database. But the exclusion > > should be done with printing some warnings. It could also be > > necessary to safely move to the next object when reindex or cluster > > operation fails on a single object due to missing prerequisite > > situations. But I don't think we might want to add such complexity to > > these "script" tools. > > Perhaps we could add something like a --skip-missing option. But isn't it a bit too complicated for the gain? I don't have a strong objection if we're fine with just allowing "--all --schema=xxx", knowing that it will works cleanly only for system catalogs. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
