Re: make \d table Collation field showing domains collation if that attribute is type of domain.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: make \d table Collation field showing domains collation if that attribute is type of domain.
Дата
Msg-id 304680.1727966806@sss.pgh.pa.us
обсуждение исходный текст
Ответ на make \d table Collation field showing domains collation if that attribute is type of domain.  (jian he <jian.universality@gmail.com>)
Список pgsql-hackers
jian he <jian.universality@gmail.com> writes:
> main changes:
> @@ -1866,7 +1866,7 @@ describeOneTableDetails(const char *schemaname,
>                 attrdef_col = cols++;
>                 attnotnull_col = cols++;
>                 appendPQExpBufferStr(&buf, ",\n  (SELECT c.collname
> FROM pg_catalog.pg_collation c, pg_catalog.pg_type t\n"
> -                                                        "   WHERE
> c.oid = a.attcollation AND t.oid = a.atttypid AND a.attcollation <>
> t.typcollation) AS attcollation");
> +                                                        "   WHERE
> c.oid = a.attcollation AND t.oid = a.atttypid and c.collname <>
> 'default' ) AS attcollation");

I doubt that this is an improvement.  It will create as many
weird cases as it removes.  (To cite just one, there is nothing
preventing somebody from creating a collation named "default".)

The existing definition seems fine to me, anyway.  What's so
wrong with treating the domain's collation as being an implicit
property of the domain type?  What you want to do hopelessly confuses
this display between attributes of the table and attributes of the
column type.

A nearby comparable case is that the "Default" column only tells
about default values applied in the table definition, not any
that might have come from the domain.  Nor does the "Check
constraints" footer tell about constraints coming from a
domain column.

            regards, tom lane



В списке pgsql-hackers по дате отправления: