[HACKERS] psql's \d and \dt are sending their complaints to different output files

Поиск
Список
Период
Сортировка
От Oleksandr Shulgin
Тема [HACKERS] psql's \d and \dt are sending their complaints to different output files
Дата
Msg-id CACACo5QgbVba3ruojeVN5kSvRvRHaxSphAOLwnU4uCdhYeZk0A@mail.gmail.com
обсуждение исходный текст
Ответы Re: [HACKERS] psql's \d and \dt are sending their complaints todifferent output files  (Dilip Kumar <dilipbalaut@gmail.com>)
Re: [HACKERS] psql's \d and \dt are sending their complaints todifferent output files  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Hello Hackers,

I wonder if it is intentional that \d complains on stderr if it cannot find relations to match, but \dt prints the message to the current output file?

postgres=# \d xxx
Did not find any relation named "xxx".
postgres=# \dt xxx
No matching relations found.

I've noticed the difference exactly because my output was (accidentally) redirected to a file and I didn't see the complaint from the 2nd backslash command.

By browsing and grepping src/bin/psql/describe.c I can see that psql_error() (used in \d) is prevalent, as opposed to fprintf() to pset.queryFout (used in \dt), but then it's a question if it should be treated as an error or not.

I think can be helpful, though rarely, to be able to send the output of \d* commands to a file.  At the same time it would be nice to see the message on stderr instead of appending to the output file, in case the relation was not found, because of less head-scratching needed to realize the problem.  So I'd vote for changing \dt (and alike) behavior to use stderr.

Regards,
--
Alex

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

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: [HACKERS] ASOF join
Следующее
От: Rajkumar Raghuwanshi
Дата:
Сообщение: [HACKERS] drop operator class..using .. left dependency behind.