pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
Rename nodes/relation.h => nodes/pathnodes.h ?
6+ messages / 5 participants
[nested] [flat]

* Rename nodes/relation.h => nodes/pathnodes.h ?
@ 2019-01-28 15:18  Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 3 replies; 6+ messages in thread

From: Tom Lane @ 2019-01-28 15:18 UTC (permalink / raw)
  To: pgsql-hackers@lists.postgresql.org

In the pluggable-storage discussion, there was some talk of renaming
nodes/relation.h to avoid confusion with the new access/relation.h
header.  I think this is a fine idea, not only because of that conflict
but because "relation.h" has never made a lot of sense as the file's
name.

After a bit of thought, I propose "pathnodes.h" as the new name.
That fits in with the other major headers in that directory
(primnodes.h, parsenodes.h, plannodes.h, execnodes.h), and it seems
like a reasonable summary of what's in it.  Admittedly, Path nodes
as such are barely a third of the file's bulk; but I don't see any
equally pithy way to describe the rest of it, unless something like
planner_data.h, which is pretty unmelodious.

(There was some mention of trying to split relation.h into multiple
files, but I fail to see any advantage in that.)

Barring objections, I'm happy to go make this happen.

			regards, tom lane




^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: Rename nodes/relation.h => nodes/pathnodes.h ?
@ 2019-01-28 15:28  Amit Langote <amitlangote09@gmail.com>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  2 siblings, 0 replies; 6+ messages in thread

From: Amit Langote @ 2019-01-28 15:28 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

On Tue, Jan 29, 2019 at 12:18 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> In the pluggable-storage discussion, there was some talk of renaming
> nodes/relation.h to avoid confusion with the new access/relation.h
> header.  I think this is a fine idea, not only because of that conflict
> but because "relation.h" has never made a lot of sense as the file's
> name.
>
> After a bit of thought, I propose "pathnodes.h" as the new name.
> That fits in with the other major headers in that directory
> (primnodes.h, parsenodes.h, plannodes.h, execnodes.h), and it seems
> like a reasonable summary of what's in it.  Admittedly, Path nodes
> as such are barely a third of the file's bulk; but I don't see any
> equally pithy way to describe the rest of it, unless something like
> planner_data.h, which is pretty unmelodious.

optnodes.h, as in optimization-related nodes?  I like pathnodes.h too though.

Thanks,
Amit




^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: Rename nodes/relation.h => nodes/pathnodes.h ?
@ 2019-01-28 16:49  Robert Haas <robertmhaas@gmail.com>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  2 siblings, 0 replies; 6+ messages in thread

From: Robert Haas @ 2019-01-28 16:49 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

On Mon, Jan 28, 2019 at 10:18 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> In the pluggable-storage discussion, there was some talk of renaming
> nodes/relation.h to avoid confusion with the new access/relation.h
> header.  I think this is a fine idea, not only because of that conflict
> but because "relation.h" has never made a lot of sense as the file's
> name.

+1.

> After a bit of thought, I propose "pathnodes.h" as the new name.
> That fits in with the other major headers in that directory
> (primnodes.h, parsenodes.h, plannodes.h, execnodes.h), and it seems
> like a reasonable summary of what's in it.  Admittedly, Path nodes
> as such are barely a third of the file's bulk; but I don't see any
> equally pithy way to describe the rest of it, unless something like
> planner_data.h, which is pretty unmelodious.

Yeah, it's not perfect, but it's better than what we've got now.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company




^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: Rename nodes/relation.h => nodes/pathnodes.h ?
@ 2019-01-28 19:47  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  2 siblings, 1 reply; 6+ messages in thread

From: Alvaro Herrera @ 2019-01-28 19:47 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@lists.postgresql.org

On 2019-Jan-28, Tom Lane wrote:

> (There was some mention of trying to split relation.h into multiple
> files, but I fail to see any advantage in that.)

Hmm, nodes/relation.h includes lots of other files and is widely
included.  If we can split it usefully, I vote for that.  However, I
failed to find any concrete proposal for doing that.  I don't have one
ATM but I'd like to keep the door open for it happening at some point.

I do like planner/pathnodes.h as a name, FWIW.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: Rename nodes/relation.h => nodes/pathnodes.h ?
@ 2019-01-29 15:31  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  0 siblings, 1 reply; 6+ messages in thread

From: Tom Lane @ 2019-01-29 15:31 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: pgsql-hackers@lists.postgresql.org

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Jan-28, Tom Lane wrote:
>> (There was some mention of trying to split relation.h into multiple
>> files, but I fail to see any advantage in that.)

> Hmm, nodes/relation.h includes lots of other files and is widely
> included.

Yup, that's why I'm trying to reduce the number of files that include it,
over in the other thread.

> If we can split it usefully, I vote for that.  However, I
> failed to find any concrete proposal for doing that.  I don't have one
> ATM but I'd like to keep the door open for it happening at some point.

The door's always open, of course, but I don't see any point in waiting
around for a hypothetical redesign.

> I do like planner/pathnodes.h as a name, FWIW.

Yeah, I think I'll go with pathnodes.h.  We'd probably keep using that
for the Path node typedefs themselves, even if somebody comes up with
a design for splitting out other things.

			regards, tom lane




^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: Rename nodes/relation.h => nodes/pathnodes.h ?
@ 2019-01-29 16:51  Andres Freund <andres@anarazel.de>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 6+ messages in thread

From: Andres Freund @ 2019-01-29 16:51 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; pgsql-hackers@lists.postgresql.org

Hi,

On 2019-01-29 10:31:39 -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > On 2019-Jan-28, Tom Lane wrote:
> > I do like planner/pathnodes.h as a name, FWIW.
> 
> Yeah, I think I'll go with pathnodes.h.  We'd probably keep using that
> for the Path node typedefs themselves, even if somebody comes up with
> a design for splitting out other things.

+1

FWIW, I can live with the #ifndef, #define, typedef .. #endif thing, I
just don't think it's pretty.

Greetings,

Andres Freund




^ permalink  raw  reply  [nested|flat] 6+ messages in thread


end of thread, other threads:[~2019-01-29 16:51 UTC | newest]

Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-01-28 15:18 Rename nodes/relation.h => nodes/pathnodes.h ? Tom Lane <tgl@sss.pgh.pa.us>
2019-01-28 15:28 ` Amit Langote <amitlangote09@gmail.com>
2019-01-28 16:49 ` Robert Haas <robertmhaas@gmail.com>
2019-01-28 19:47 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2019-01-29 15:31   ` Tom Lane <tgl@sss.pgh.pa.us>
2019-01-29 16:51     ` Andres Freund <andres@anarazel.de>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox