Re: Bug in psql - Mailing list pgsql-bugs
| From | Chris BSomething |
|---|---|
| Subject | Re: Bug in psql |
| Date | |
| Msg-id | CADrHaBHPmbUXXYyHgcaC6poEWbsLnVxd3vCBQZw+NB72iCJ9ow@mail.gmail.com Whole thread Raw |
| In response to | Bug in psql (Chris BSomething <xpusostomos@gmail.com>) |
| Responses |
Re: Bug in psql
|
| List | pgsql-bugs |
On Mon, 3 Feb 2025 at 10:12, David G. Johnston <david.g.johnston@gmail.com> wrote:
You can quibble with our definitions but they probably aren't going to change (and a bug report isn't the best place to try anyway). The glossary says:RelationThe generic term for all objects in a database that have a name and a list of attributes defined in a specific order. Tables, sequences, views, foreign tables, materialized views, composite types, and indexes are all relations.More generically, a relation is a set of tuples; for example, the result of a query is also a relation.
If an index is a set of tuples, there is no way for a user to see those tuples, know what attributes they have, know what order they're in, or what their contents are. One might surmise a hash index has hash values and a pointer to page tables, but that's all invisible to a user. An index does not fit the technical, mathematical or even the postgresql documented definition which says a relation is a "mathematical term for a table", and goes on to talk about how SQL queries relations, which you can't do on an index.
And even if indexes were relations, \di putting output saying "List of relations", at best it would be SOME relations, and therefore still wrong. And yet \dS manages the amazing feat of saying "Index..." if we're talking about an index.... it doesn't attempt to befuddle you by calling it a relation, like \di does.
But if you think this is great, why not change the help text to have 20 commands to "list relations", since they're all relations apparently, and informing the user beyond that is apparently overkill.
And the design methodology given extends from that.
What design methodology? Sounds like your understanding of pgsql internal design is leaking into the user interface.
I agree with this premise. It's still a matter of R&D to find the violation and fix them - without confounding things with also tryIng to declassify indexes as relations.
Who exactly in user land is edified by referring to indexes as relations?
On Mon, 3 Feb 2025 at 10:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
It could be argued that at the level of detail that's possible in this
help summary, their functions *are* the same. The family of commands
that includes \dE will show you Schema, Name, Type, Owner, which are
properties that all relations have so they are sensible to show in a
list that might include any type of relation. On the other hand,
\det shows Schema, Table, Server (and \det+ includes FDW options),
so it is only applicable to foreign tables. But we don't have the
space in \h output to go into the specific output columns. That's
pretty much left to the user to discover by trying things.
If I hired a programmer, and he couldn't write 2 functions because he couldn't think up 2 different names for similar, and yet different functions, I would fire him. Sounds like one is "list foreign tables (basic info)" and one is "list foreign tables (foreign info)" or some such. Surely it's not beyond a moderately talented person to come up with something. More time has already been expended arguing pedantic points than would take to fix it.
pgsql-bugs by date: