Sami I

Thanks for the report @michaelpq After we spoke offline, I spent time looking further into this. What I observed is the follows: 1. skipping over setup_scan_method_enforcement https://github.com/ossc-db/pg_hint_plan/blob/master/pg_hint_plan.c#L3955-L3956 does not prevent...

> For now, I would like to choose a revert of https://github.com/ossc-db/pg_hint_plan/commit/684986acc3b3156aaf22c1571cd44dd34059a346 & friends on stable branches, getting back to the previous-still-somewhat-broken behavior. With the above said, I do agree...

I agree. I'll submit a patch for Parallel Hint tests ( including those mentioned above ).

Attached are tests that cover several of the gaps discovered in this discussion: 1/ Ensure that Parallel enforcement does not break when a non-existent index is used in an IndexScan...

>The patch you are proposing for the additional tests has no explanation about what's being done, I hesitated doing that as it's not the norm to add much documentation to...

After second thought, showing that the non-existing index does not prevent parallel hint enforcement is not necessary. So, the test now shows the important part. For empty tables, parallel hints...

> Feature: plug-in query IDs rather than query string normalizations for the hint table. This has been on the table for some time, and I really want to get rid...

> feature IMO as the current hint_table is hard to use when dealing with > large sql text or the same sql text that could have differences in comments >...

I took another look. If the user creates the ```pg_hint_plan``` extension, this will not be an issue as the ```hints``` table is created as part of the extension. It also...

> 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:...