Hello Tom,
On 2020-11-18 16:49, Tom Lane wrote:
> Tels <nospam-pg-abuse@bloodgate.com> writes:
>> On 2020-11-18 06:06, Michael Paquier wrote:
>>> On Mon, Nov 16, 2020 at 10:14:10PM -0500, Tom Lane wrote:
>>>> Agreed, I'm not trying to block this patch. Just wishing
>>>> there were a better way.
>
>> To me the code looks like a prime candidate for "data-driven"
>> refactoring.
>> It should be redone as generic code that reads a table of rules with
>> params and then checks and applies each. Thus the repetitive code
>> would
>> be replaced by a bit more generic code and a lot of code-free data.
>
> In the past I've looked into whether the rules could be autogenerated
> from the backend's grammar. It did not look very promising though.
> The grammar isn't really factorized appropriately -- for instance,
> tab-complete has a lot of knowledge about which kinds of objects can
> be named in particular places, while the Bison productions only know
> that's a "name". Still, the precedent of ECPG suggests it might be
> possible to process the grammar rules somehow to get to a useful
> result.
Hm, that would be even better, for now I was just thinking that
code like this:
IF RULE_A_MATCHES THEN
DO STUFF A
ELSE IF RULE_B_MATCHES THEN
DO_STUFF_B
ELSE IF RULE_C_MATCHES THEN
DO_STUFF_C
...
should be replaced by
RULE_A MATCH STUFF
RULE_B MATCH STUFF
RULE_C MATCH STUFF
...
FOREACH RULE DO
IF RULE.MATCH THEN
DO RULE.STUFF
END FOREACH
Even if the rules would be manually created (converted from the current
code), that would be more compact and probably less error-prone.
Creating the rule automatically turns this into a completely different
story.
--
Best regards,
Tels