Re: Bug in psql

On Mon, 3 Feb 2025 at 10:12, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)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:
>
> Relation
> The 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(at)sss(dot)pgh(dot)pa(dot)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.