Thread: \d failing to find uppercased object names
Hello,
some app created tables ussing uppercase letters in table names (this app was migrated from mysql). One tries to use \d to search tables info:
ru=# \d pnct_Board
Did not find any relation named "pnct_Board".
Of course, it works with ":
ru=# \d "pnct_Board"
Table "public.pnct_Board"
Column | Type | Modifiers
-------------+----------+-----------------------------------------------------------
id | bigint | not null default nextval('"pnct_Board_id_seq"'::regclass)
<...>
Could this be considered as gotcha?
The thing is that Postgres reply is pretty much clear:
> Did not find any relation named "pnct_Board".
, but table "pnct_Board" does exist in the system, so Postgres' reply is obviously incorrect.
Version: 9.2.1
2013/1/24 Nikolay Samokhvalov <samokhvalov@gmail.com>: > some app created tables ussing uppercase letters in table names (this app > was migrated from mysql). One tries to use \d to search tables info: > > ... > > Could this be considered as gotcha? > > The thing is that Postgres reply is pretty much clear: > > Did not find any relation named "pnct_Board". > , but table "pnct_Board" does exist in the system, so Postgres' reply is > obviously incorrect. Take a look at this section in the docs: http://www.postgresql.org/docs/current/interactive/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS This is expected behavior. -- Victor Y. Yegorov
On 01/24/2013 08:51 PM, Виктор Егоров wrote: > 2013/1/24 Nikolay Samokhvalov <samokhvalov@gmail.com>: >> some app created tables ussing uppercase letters in table names (this app >> was migrated from mysql). One tries to use \d to search tables info: >> >> ... >> >> Could this be considered as gotcha? >> >> The thing is that Postgres reply is pretty much clear: >> > Did not find any relation named "pnct_Board". >> , but table "pnct_Board" does exist in the system, so Postgres' reply is >> obviously incorrect. > Take a look at this section in the docs: > http://www.postgresql.org/docs/current/interactive/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS > > This is expected behavior. Yep. You could propose a patch for a case-insensitive modifier for \d, though I don't know how well it'd be received. (Or is there a way to do that using psql's wildcards already? In this simple case \d pnct_* would work, but not in the general case where you might be looking for TaBLeNAMe) -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services