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
|
Список | 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 по дате отправления: