On Mon, Jul 15, 2024 at 6:44 AM David Rowley <dgrowleyml@gmail.com> wrote:
> Unfortunately, this wouldn't align with the goals of the patch. Going
> back to Melih's opening paragraph in the initial email, he mentions
> that there's currently no *reliable* way to determine the parent/child
> relationship in this view.
>
> There's been a few different approaches to making this reliable. The
> first patch had "parent_id" and "id" columns. That required a WITH
> RECURSIVE query. To get away from having to write such complex
> queries, the "path" column was born. I'm now trying to massage that
> into something that's as easy to use and intuitive as possible. I've
> gotta admit, I don't love the patch. That's not Melih's fault,
> however. It's just the nature of what we're working with.
I'm not against what you're trying to do here, but I feel like you
might be over-engineering it. I don't think there was anything really
wrong with what Melih was doing, and I don't think there's anything
really wrong with converting the path to an array of strings, either.
Sure, it might not be perfect, but future patches could always remove
the name duplication. This is a debugging facility that will be used
by a tiny minority of users, and if some non-uniqueness gets
reintroduced in the future, it's not a critical defect and can just be
fixed when it's noticed. That said, if you want to go with the integer
IDs and want to spend more time massaging it, I also think that's
fine. I simply don't believe it's the only way forward here. YMMV, but
my opinion is that none of these approaches have such critical flaws
that we need to get stressed about it.
--
Robert Haas
EDB: http://www.enterprisedb.com
