Обсуждение: Rename nodes/relation.h => nodes/pathnodes.h ?
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
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
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
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
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
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