On Wed, Oct 13, 2021 at 09:24:53AM -0400, Robert Haas wrote:
> > Splitting the pattern on all the dots and throwing away any additional
> > leftmost fields is a bug, ...
>
> I also agree with you right up to here.
>
> > and when you stop doing that, passing additional dots through to the POSIX
> > regular expression for processing is the most natural thing to do. This
> > is, in fact, how v14 works. It is a bit debatable whether treating the
> > first dot as a separator and the additional dots as stuff to be passed
> > through is the right thing, so we could call the v14 behavior a
> > mis-feature, but it's not as clearcut as the discussion upthread suggested.
> > Reverting to v13 behavior seems wrong, but I'm now uncertain how to
> > proceed.
>
> But not this part, or at least not entirely.
>
> If we pass the dots through to the POSIX regular expression, we can
> only do that either for the table name or the schema name, not both -
> either the first or last dot must mark the boundary between the two.
> That means that you can't use all the same regexy things for one as
> you can for the other, which is a strange system. I knew that your
> patch made it do that, and I committed it that way because I didn't
> think it really mattered, and also because the whole system is already
> pretty strange, so what's one more bit of strangeness?
Rather than trying to guess at the meaning of each '.' based on the total
string. I wonder, if we could for v15 require '.' to be spelled in longer way
if it needs to be treated as part of the regex.
Perhaps requiring something like '(.)' be used rather than a bare '.'
might be good enough and documenting otherwise it's really a separator?
I suppose we could also invent a non-standard class as a stand in like
'[::any::]', but that seems kinda weird.
I think it might be possible to give better error messages long term
if we knew what '.' should mean without looking at the whole thing.
Garick