Re: After upgrade from version9.4.1 to 10.15, changes on the table structure
От | Tom Lane |
---|---|
Тема | Re: After upgrade from version9.4.1 to 10.15, changes on the table structure |
Дата | |
Msg-id | 1055940.1616595998@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | After upgrade from version9.4.1 to 10.15, changes on the table structure ("Mundla, Sankar" <Sankar.Mundla@rsa.com>) |
Список | pgsql-bugs |
"Mundla, Sankar" <Sankar.Mundla@rsa.com> writes: > [ dump and reload converts ] > "ck_am_dummy_simulation" CHECK (domain_object_type::text = ANY (ARRAY['PRINCIPAL'::character varying, 'TOKEN'::charactervarying]::text[])) > [ into ] > "ck_am_dummy_simulation" CHECK (domain_object_type::text = ANY (ARRAY['PRINCIPAL'::character varying::text, 'TOKEN'::charactervarying::text])) > Why is this behavior ? pg_dump, like psql, prefers to show implicit casts explicitly, to reduce the risk of the expression being interpreted differently when reloaded. So while you wrote the array without any cast to begin with, you get the first form in the dump. However, the parser treats array[...]::something[] differently from a bare array[]. The cast to "something" is applied to each array element immediately. The reason for that is that if we just transformed array[...] without applying the knowledge that the final type must be "something", we might get an unnecessary parse failure from inability to resolve a common type for the array elements. (The parser has no way to know, of course, that some previous cycle of processing successfully resolved a common type for the elements. This behavior is unnecessary in this context, but it does help for manually-entered expressions.) So you end up with something that looks a little different. It's semantically equivalent though, so I see no bug here. regards, tom lane
В списке pgsql-bugs по дате отправления: