Обсуждение: processSQLNamePattern() analog

Hello!

I'm working on adding to psql commands to print information about access methods. I ran into the following problem:
The command "\dA" (as well as several commands that I write) accept the access method name template. The resulting
templateis processed by the processSQLNamePattern () function, which means that a template with a schema can be fed to
theinput. But since the access method does not have schema, it's needed to handle somehow a command like "\dA foo. *".
Atthis point, the command will display a full list of access methods, not paying attention to the presence of the
schemaname in the template. Function processSQLNamePattern () allows you to filter out the output, if for example to
comparethe name of the schema not with any value of the column, but with NULL. But in this case, patterns like "\dA
*.*"will not be eliminated.
 

I also need a possibility to handle templates of type "schema.table.column", but the function processSQLNamePattern ()
canprocess only "schema.table".
 

In this regard, the question: is it still worth adding a new function capable of handling these cases, or should the
psqluser deal with output like "all_schemas.mathed_table.mathed_column"? And is it worth fixing the current behavior of
"\dAfoo.*"?
 

Sergey Cherkashin <s.cherkashin@postgrespro.ru> writes:
> The command "\dA" (as well as several commands that I write) accept the access method name template. The resulting
templateis processed by the processSQLNamePattern () function, which means that a template with a schema can be fed to
theinput. But since the access method does not have schema, it's needed to handle somehow a command like "\dA foo. *".
Atthis point, the command will display a full list of access methods, not paying attention to the presence of the
schemaname 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.

Also, there are cases like \dd where the same name pattern is applied to
multiple kinds of objects.  (I'm not sure if that particular command
covers both schema-qualified and not-schema-qualified objects today,
but surely it might in future.)  So being picky would definitely not work
well for that.

> 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.

            regards, tom lane

Thanks for the answer.

On Ср, 2018-06-06 at 13:06 -0400, Tom Lane wrote:
> Sergey Cherkashin <s.cherkashin@postgrespro.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.