Re: patch: remove redundant code from pl_exec.c

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch: remove redundant code from pl_exec.c
Date: 2010-12-17 15:41:50
Message-ID: AANLkTimK5twGzpA+rP0HJbJm1-YtNFm7FqXUrkaOWOTq@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/12/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2010/12/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> I'm not really impressed with this idea: there's no a priori reason
>>> that all those loop types would necessarily have exactly the same
>>> control logic.
>
>> There is no reason why the processing should be same, but actually is same.
>
> Yes, and it might need to be different in future, whereupon this patch
> would make life extremely difficult.

Do you know about some possible change?

I can't to argument with this argument. But I can use a same argument.
Isn't be more practical to have a centralized management for return
code? There is same probability to be some features in future that
will need a modify this fragment - for example a new return code
value. Without centralized management, you will have to modify four
fragments instead one.

Regards

Pavel Stehule

>
>                        regards, tom lane
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-12-17 15:47:38 Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)
Previous Message Tom Lane 2010-12-17 15:41:06 Re: ps_status on fastpath