Re: Remove redundant variable from transformCreateStmt - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Remove redundant variable from transformCreateStmt
Date
Msg-id 20210429183942.GA10172@alvherre.pgsql
Whole thread Raw
In response to Re: Remove redundant variable from transformCreateStmt  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Remove redundant variable from transformCreateStmt  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On 2021-Apr-29, Tom Lane wrote:

> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > I'd do it like this.  Note I removed an if/else block in addition to
> > your changes.
> 
> > I couldn't convince myself that this is worth pushing though; either we
> > push it to all branches (which seems unwarranted) or we create
> > back-patching hazards.
> 
> Yeah ... an advantage of the if/else coding is that it'd likely be
> simple to extend to cover additional statement types, should we ever
> wish to do that.  The rendering you have here is nice and compact,
> but it would not scale up well.

That makes sense.  But that part is not in Amul's patch -- he was only
on about removing the is_foreign_table Boolean.  If I remove the if/else
block change, does the rest of the patch looks something we'd want to
have?  I kinda agree that the redundant variable is "ugly".  Is it worth
removing?  My hunch is no.

-- 
Álvaro Herrera                            39°49'30"S 73°17'W



pgsql-hackers by date:

Previous
From: Richard Yen
Date:
Subject: Re: Patch to allow pg_filedump to support reading of pg_filenode.map
Next
From: Justin Pryzby
Date:
Subject: Re: Patch to allow pg_filedump to support reading of pg_filenode.map