Hi,
On 2014-09-02 15:04, Heikki Linnakangas wrote:
I think this patch has been thoroughly reviewed now. Committed, thanks!
Thank you, Heikki. And also big thanks to Fabien for the review!
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 09/02/2014 11:52 AM, Fabien COELHO wrote:
I've changed the loop slightly. Do you find this more readable than the way
the loop was previously written?
It is 50% better:-)
It is no big deal, but I still fail to find the remaining continue as
usefull in this case. If you remove the "contin
Hello Marko,
I've changed the loop slightly. Do you find this more readable than the way
the loop was previously written?
It is 50% better:-)
It is no big deal, but I still fail to find the remaining continue as
usefull in this case. If you remove the "continue" line and invert the
condit
On 2014-08-12 13:23, I wrote:
The compile-time raise parameter checking is a good move.
3 minor points:
- I would suggest to avoid "continue" within a loop so that the code is
simpler to understand, at least for me.
I personally find the code easier to read with the continue.
I've changed t
2014-08-12 19:14 GMT+02:00 Fabien COELHO :
>
> one note: this patch can enforce a compatibility issues - a partially
>> broken functions, where some badly written RAISE statements was executed
>> newer.
>>
>
> I am not against this patch, but it should be in extra check probably ??
>>
>
> I'm no
one note: this patch can enforce a compatibility issues - a partially
broken functions, where some badly written RAISE statements was executed
newer.
I am not against this patch, but it should be in extra check probably ??
I'm not sure about what you mean by "it should be in extra check".
2014-08-12 15:09 GMT+02:00 Fabien COELHO :
>
> Hello,
>
>
> - I would suggest to avoid "continue" within a loop so that the code is
>>> simpler to understand, at least for me.
>>>
>>
>> I personally find the code easier to read with the continue.
>>
>
> Hmmm. I had to read the code to check it, a
Hello,
- I would suggest to avoid "continue" within a loop so that the code is
simpler to understand, at least for me.
I personally find the code easier to read with the continue.
Hmmm. I had to read the code to check it, and I did it twice. The point is
that there is 3 exit points instead
Hi Fabien,
On 8/12/14 1:09 PM, Fabien COELHO wrote:
Here's a patch for making PL/PgSQL throw an error during compilation (instead
of runtime) if the number of parameters passed to RAISE don't match the
number of placeholders in error message. I'm sure people can see the pros of
doing it this wa
Hello Marko,
Here's a patch for making PL/PgSQL throw an error during compilation (instead
of runtime) if the number of parameters passed to RAISE don't match the
number of placeholders in error message. I'm sure people can see the pros of
doing it this way.
Patch scanned, applied & tested
Hi
2014-07-26 20:39 GMT+02:00 Marko Tiikkaja :
> Me again,
>
> Here's a patch for making PL/PgSQL throw an error during compilation
> (instead of runtime) if the number of parameters passed to RAISE don't
> match the number of placeholders in error message. I'm sure people can see
> the pros of
Me again,
Here's a patch for making PL/PgSQL throw an error during compilation
(instead of runtime) if the number of parameters passed to RAISE don't
match the number of placeholders in error message. I'm sure people can
see the pros of doing it this way.
.marko
*** a/src/pl/plpgsql/src/pl
12 matches
Mail list logo