Michael Paquier

> So, ping :-) Yep. I'm aware of that. But my schedule does not give me the possibility to get back to that until the 17th of August. So.

> I finished updating .po files for the next release on PG17 branch. Thanks Yamada-san!

Here is an update. I have most of the things I wanted to tackle for the moment in the tree, remains: - https://github.com/ossc-db/pg_hint_plan/issues/161, this is not really mandatory for this...

One thing that we could do is a check callback for the GUC to ease the error message when using a SET. Like for check_default_table_access_method, it cannot be perfect: it...

> To be sure, you are thinking to check if the pg_hint_plan extension has been created in the guc check hook? Or check that the table exists. Both require a...

Hmm. Is an error message the best choice though? If pg_hint_plan.enable_hint_table is enabled in postgresql.conf, then one would get an error for basically all queries run in the backend. I...

> Ideally we should document that enabling it globally is likely to be a terrible idea and should be done at the database level using ALTER DATABASE SET. Yeah, agreed...

> Given those requirements I'm not sure that the extra infrastructure to handle it will be really worth it. I guess that you are also referring here to the part...

> Having such a cache will likely improve performance, as @samimseih pointed, but I don't think it's really trivial to do. I'm biased on the risk vs benefit risk on...

> it would probably be better to add a check in get_hints_from_table() that the table exist (like trying to get its oid or something) and raise a clear error message...