Обсуждение: BUG #13899: \det ignores visibility; patch attached

The following bug has been logged on the website:

Bug reference:      13899
Logged by:          Reece Hart
Email address:      reece@harts.net
PostgreSQL version: 9.5.0
Operating system:   linux
Description:

Patch:

--- src/bin/psql/describe.c.orig    2016-01-28 16:22:33.782890246 -0800
+++ src/bin/psql/describe.c    2016-01-28 16:31:08.052200101 -0800
@@ -4412,7 +4412,8 @@
                              "d.objoid = c.oid AND d.objsubid = 0\n");

     processSQLNamePattern(pset.db, &buf, pattern, false, false,
-                          NULL, "n.nspname", "c.relname", NULL);
+                          NULL, "n.nspname", "c.relname",
+                          "pg_catalog.pg_table_is_visible(c.oid)");

     appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");

On Fri, Jan 29, 2016 at 9:34 AM,  <reece@harts.net> wrote:
> --- src/bin/psql/describe.c.orig        2016-01-28 16:22:33.782890246 -0800
> +++ src/bin/psql/describe.c     2016-01-28 16:31:08.052200101 -0800
> @@ -4412,7 +4412,8 @@
>                                                          "d.objoid = c.oid AND d.objsubid = 0\n");
>
>         processSQLNamePattern(pset.db, &buf, pattern, false, false,
> -                                                 NULL, "n.nspname", "c.relname", NULL);
> +                                                 NULL, "n.nspname", "c.relname",
> +                                                 "pg_catalog.pg_table_is_visible(c.oid)");
>
>         appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");

Hm. I don't think so, the current behavior looks to be on purpose. \dE
instead can be used to match the visibility with search_path, so I
would rather modify the documentation to mention that \d[Eitstv]
matches the schema visibility in search_path instead and let \det
alone.
--
Michael

Michael Paquier <michael.paquier@gmail.com> writes:
> On Fri, Jan 29, 2016 at 9:34 AM,  <reece@harts.net> wrote:
>> --- src/bin/psql/describe.c.orig        2016-01-28 16:22:33.782890246 -0800
>> +++ src/bin/psql/describe.c     2016-01-28 16:31:08.052200101 -0800
>> @@ -4412,7 +4412,8 @@
>> "d.objoid = c.oid AND d.objsubid = 0\n");
>>
>> processSQLNamePattern(pset.db, &buf, pattern, false, false,
>> -                                                 NULL, "n.nspname", "c.relname", NULL);
>> +                                                 NULL, "n.nspname", "c.relname",
>> +                                                 "pg_catalog.pg_table_is_visible(c.oid)");
>>
>> appendPQExpBufferStr(&buf, "ORDER BY 1, 2;");

> Hm. I don't think so, the current behavior looks to be on purpose. \dE
> instead can be used to match the visibility with search_path, so I
> would rather modify the documentation to mention that \d[Eitstv]
> matches the schema visibility in search_path instead and let \det
> alone.

No, I think it's just plain broken.  There are two bugs there, not just
one, as can be seen by comparison of this processSQLNamePattern call to
every other one that's dealing with schema-qualifiable names.  It should
be more like

    processSQLNamePattern(pset.db, &buf, pattern, false, false,
                          "n.nspname", "c.relname", NULL,
                          "pg_catalog.pg_table_is_visible(c.oid)");

As-is, it's passing nspname for "namevar" and relname for "altnamevar".
That sort of manages to not fail for unqualified names, but even there,
I fail to see how matching to schema names is anything but a bug.

This code came in with some other \d commands for other FDW-related
objects that do not have schema-qualified names, so I guess that it
was just mis-copied-and-pasted from one of those.

            regards, tom lane