> As far as I recall it was an
> intentional design decision, and to adjust newa->list_end in such
> scenarios we need to solve the original problem of finding an end
> location of any arbitrary expression,
I'm not sure I follow. How would we adjust newa->list_end?
> > > * Independently from that, it sounds like a good idea to have protection
> > > from overlapping constants when generating normalized query. It could
> > > be done in the same way as the previous bug was fixed. In
> > > fill_in_constant_lengths we currently check for duplicated constants:
> > >
> > > locs[i].location == locs[i - 1].location
> > >
> > > then set length = -1 for those. I think it's worth extending it to
> > > check for overlapping with the previous constant, something like:
> > >
> > > (locs[i].location == locs[i - 1].location ||
> > > locs[i].location <= locs[i - 1].location + locs[i - 1].length)
> >
> > Yeah, this may be a good defensive check to add, but it's
> > not going to be useful for this issue.
>
> It is, the proposed change helps to avoid the crash pointed out in this
> thread. It might not be the right solution for the reasons discussed so
> far, but as a general defensive mechanism makes total sense to me (maybe
> with an assert to highlight any potential future problem).
Yeah, we should not assume this is not expected behavior. Here is one
from the regress tests in which overlaps can occur:
```
CREATE TABLE shighway (
surface text
) INHERITS (road);
INSERT INTO shighway
SELECT a.*, 'asphalt'
FROM road a, road b
WHERE a.name ~ 'State Hwy.*';
```
--
Sami Imseih
Amazon Web Services (AWS)
