[HACKERS] psql's \d and \dt are sending their complaints to different output files - Mailing list pgsql-hackers

From Oleksandr Shulgin
Subject [HACKERS] psql's \d and \dt are sending their complaints to different output files
Date
Msg-id CACACo5QgbVba3ruojeVN5kSvRvRHaxSphAOLwnU4uCdhYeZk0A@mail.gmail.com
Whole thread Raw
Responses 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>)
List 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 by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: [HACKERS] ASOF join
Next
From: Rajkumar Raghuwanshi
Date:
Subject: [HACKERS] drop operator class..using .. left dependency behind.