Re: processSQLNamePattern() analog

Thanks for the answer.

On Ср, 2018-06-06 at 13:06 -0400, Tom Lane wrote:
> Sergey Cherkashin <s(dot)cherkashin(at)postgrespro(dot)ru> writes:
> >
> > The command "\dA" (as well as several commands that I write) accept
> > the access method name template. The resulting template is
> > processed by the processSQLNamePattern () function, which means
> > that a template with a schema can be fed to the input. But since
> > the access method does not have schema, it's needed to handle
> > somehow a command like "\dA foo. *". At this point, the command
> > will display a full list of access methods, not paying attention to
> > the presence of the schema name in the template.
> I don't see a particular problem with this.  The \d commands in
> general
> are meant to accept handwritten input, so they should err on the side
> of being forgiving.  I do not see how it would be an improvement to
> throw an error complaining that the pattern shouldn't have been
> schema-qualified for this particular type of name, nor would the
> alternative possibility that "*.*" silently refuses to match anything
> be a great idea.

OK, I leave it alone.

> > I also need a possibility to handle templates of type
> > "schema.table.column",
> Why?  I think you'd be best off not going there, because it will
> create confusion against the SQL-standard-mandated possibility of
> "database.schema.table".  We don't really support that notation
> today in most contexts, but it might be a problem in future.

As for the new function, I meant the possibility of getting from the
function information about on which blocks ("schema" or "table") it
divided the template, how many of these blocks, etc. That is, to make
it possible to understand outside the function, if we are dealing with
the name of the schema or column. Or maybe we should have possibility
to limit what blocks we can work with.
But at the moment I think it is
really enough to make user manage with pattenrs by himself.

Regards,
Sergey Cherkashin.