Daniel Gustafsson writes:
> On 27 Jul 2017, at 19:40, Tom Lane wrote:
>> listTables and listDbRoleSettings print a custom message rather than
>> an empty table for no matches (but in QUIET mode they just do the
>> latter). I think that's actually a good decision for listDbRoleSettings,
>> becaus
> On 27 Jul 2017, at 19:40, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 19 Jun 2017, at 17:32, Tom Lane wrote:
>>> So, if we're getting into enforcing consistency in describe.c, there's
>>> lots to do.
>
>> Addressed in attached patch, see list of patches below.
>
> I've pushed most
Daniel Gustafsson writes:
>> On 19 Jun 2017, at 17:32, Tom Lane wrote:
>> So, if we're getting into enforcing consistency in describe.c, there's
>> lots to do.
> Addressed in attached patch, see list of patches below.
I've pushed most of this. There are a couple of remaining
inconsistencies:
> On 19 Jun 2017, at 17:32, Tom Lane wrote:
>
> So, if we're getting into enforcing consistency in describe.c, there's
> lots to do.
>
> * listDbRoleSettings does this for a server too old to have the desired
> feature:
>
> fprintf(pset.queryFout,
> _("No per-databas
"David G. Johnston" writes:
> On Mon, Jun 19, 2017 at 2:53 PM, Tom Lane wrote:
>> Where are you reading that?
> https://www.postgresql.org/docs/9.6/static/app-psql.html
> First sentence:
> "For each relation (table, view, index, sequence, or foreign table) or
> composite type matching the patte
On Mon, Jun 19, 2017 at 2:53 PM, Tom Lane wrote:
> "David G. Johnston" writes:
>> The docs also indicate that we don't include materialized views as
>> part of "\d" which seems like an oversight somewhere.
>
> Where are you reading that?
https://www.postgresql.org/docs/9.6/static/app-psql.html
"David G. Johnston" writes:
> The docs also indicate that we don't include materialized views as
> part of "\d" which seems like an oversight somewhere.
Where are you reading that? Experimentation shows that "\d" does include
matviews, and that matches the code, which has this as the default
exp
On Mon, Jun 19, 2017 at 2:25 PM, Peter Eisentraut
wrote:
> On 6/19/17 09:00, Oleksandr Shulgin wrote:
>> 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 f
Peter Eisentraut writes:
> On 6/19/17 09:00, Oleksandr Shulgin wrote:
>> postgres=# \d xxx
>> Did not find any relation named "xxx".
>> postgres=# \dt xxx
>> No matching relations found.
> I think this is intentional.
> The first command is "show me relation xxx", and that gives an error
> messa
On 6/19/17 09:00, Oleksandr Shulgin wrote:
> 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
Dilip Kumar writes:
> On Mon, Jun 19, 2017 at 6:30 PM, Oleksandr Shulgin
> wrote:
>> 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 ca
On Mon, Jun 19, 2017 at 6:30 PM, Oleksandr Shulgin
wrote:
> 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
> fo
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 differen
13 matches
Mail list logo
