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