Re: processSQLNamePattern() analog

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: processSQLNamePattern() analog
Дата
Msg-id 13507.1528304784@sss.pgh.pa.us
обсуждение исходный текст
Ответ на processSQLNamePattern() analog  (Sergey Cherkashin <s.cherkashin@postgrespro.ru>)
Ответы Re: processSQLNamePattern() analog  (Sergey Cherkashin <s.cherkashin@postgrespro.ru>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?