Re: proposal psql \gdesc

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal psql \gdesc
Date: 2017-05-09 21:00:19
Message-ID: alpine.DEB.2.20.1705092234510.8943@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


>> What about detecting the empty result (eg PQntuples()==0?) and writing
>> "Empty result" instead of the strange looking empty table above? That would
>> just mean skipping the PrintQueryResult call in this case?
>
> PQntuples == 0 every time - the query is not executed.

I meant to test the query which collects type names, which is executed?

Or check that PQnfields() == 0 on the PQdescribePrepared() result, so
that there is no need to execute the type name collection query?

> For the case "SELECT;" the empty table is correct.

Ok. Then write "Empty table"?

> For TRUNCATE and similar command I am not sure. The empty table is maybe
> unusual, but it is valid - like "SELECT;".

I would partly disagree:

"SELECT;" does indeed return an empty relation, so I agree that an empty
table is valid whether spelled out as "Empty table" or explicitly.

However, ISTM that "TRUNCATE stuff;" does *NOT* return a relation, so
maybe "No table" would be ok, but not an empty table... ?!

So I could be okay with both:

SELECT \gdesc
-- "Empty table" or some other string
Or
-- Name | Type

Although I prefer the first one, because the second looks like a bug
somehow: I asked for a description, but nothing is described... even if
the answer is somehow valid, it looks pretty strange.

The same results do not realy suit "TRUNCATE Foo \gdesc", where "No table"
would seem more appropriate?

In both case, "Empty result" is kind of neutral, it does not promise a
table or not. Hmmm. At least not too much. Or maybe some other string such
as "Nothing" or "No result"?

Now I wonder whether the No vs Empty cases can be distinguished?

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Verite 2017-05-09 21:00:31 Re: export import bytea from psql
Previous Message Tom Lane 2017-05-09 20:14:20 Re: CTE inlining