Re: minor fix for acquire_inherited_sample_rows

Amit Langote wrote:
> On Thu, Apr 26, 2018 at 9:54 PM, Ashutosh Bapat
> <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
> > On Thu, Apr 26, 2018 at 1:08 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >> +1. I think we're really abusing equalTupleDescs() for purposes for
> >> which it was not invented. Instead of changing it, let's invent a new
> >> function that tests for the thing partitioning cares about (same
> >> ordering of the same columns with the same type information) and call
> >> it logicallyEqualTupleDescs() or something like that.
> >
> > Why don't we just rely on the output of convert_tuples_by_name(),
> > which it seems is always called right now? What's advantage of adding
> > another tuple descriptor comparison?
>
> The patch I mentioned in my email above does more or less that (what
> you're saying we should do). In fact it even modifies
> convert_tuple_by_name and convert_tuple_by_name_map to remove some
> redundant computation. See that patch here if you're interested:
>
> https://www.postgresql.org/message-id/825031be-942c-8c24-6163-13c27f217a3d%40lab.ntt.co.jp

Yeah, I didn't like the additional nullness checks in that patch. I was
thinking it might be saner to create a new struct with the AttrNumber *
array, its length and a boolean flag indicating a no-op conversion.
Then we can call map_variable_attnos unconditionally and it does nothing
if the flag is set. This localizes the ugliness.

I'm not sure if this idea is better than Robert's logicallyEqualTupleDescs().
Maybe we can use both in different places.

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