On Wed, 2005-01-19 at 18:39 +1100, Neil Conway wrote:
> Attached is a revised patch. Barring any objections, I intend to apply
> this sometime tomorrow.
Applied.
-Neil
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Tue, 2005-01-18 at 00:54 -0500, Tom Lane wrote:
> I won't stand in the way of you doing this
Attached is a revised patch. Barring any objections, I intend to apply
this sometime tomorrow.
-Neil
Index: src/backend/parser/parse_expr.c
Neil Conway <[EMAIL PROTECTED]> writes:
> Why I think the patch is a good idea: 900 line functions are almost
> universally bad (in fact, I'd be tempted to remove the "almost").
[ shrug... ] 900 line functions that consist of absolutely independent
case arms are not any harder to read than the alt
On Thu, 2004-10-28 at 16:49 +1000, Neil Conway wrote:
> This patch refactors transformExpr(): rather than being a monsterous 900
> line function, it breaks it up into numerous sub-functions that are
> invoked by transformExpr() for individual expression types, in the style
> of transformStmt().
I
James William Pye wrote:
-- Start of PGP signed section.
> On Thu, 2004-10-28 at 18:00, Neil Conway wrote:
> > I think the code is more readable this way.
>
> FWIW, I'm +1 on the patch for the above reason.
I liked the large case statement myself. I don't like breaking things
into pieces when th
On Thu, 2004-10-28 at 18:00, Neil Conway wrote:
> I think the code is more readable this way.
FWIW, I'm +1 on the patch for the above reason.
--
Regards,
James William Pye
signature.asc
Description: This is a digitally signed message part
On Fri, 2004-10-29 at 00:17, Tom Lane wrote:
> I don't actually find this to be an improvement. What's the point?
> Since all the switch arms are independent, you haven't really done
> anything at all to improve the comprehensibility of the code...
I think the code is more readable this way. The
Neil Conway <[EMAIL PROTECTED]> writes:
> This patch refactors transformExpr(): rather than being a monsterous 900
> line function, it breaks it up into numerous sub-functions that are
> invoked by transformExpr() for individual expression types, in the style
> of transformStmt().
I don't actually
This patch refactors transformExpr(): rather than being a monsterous 900
line function, it breaks it up into numerous sub-functions that are
invoked by transformExpr() for individual expression types, in the style
of transformStmt().
I think this patch is reasonably safe for HEAD (it mostly just
r
