Обсуждение: Doc says nothing about wether CREATE OR REPLACE VIEW can change the COLLATION of an existing field
Doc says nothing about wether CREATE OR REPLACE VIEW can change the COLLATION of an existing field
От
PG Doc comments form
Дата:
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/14/sql-createview.html Description: What the doc says about CREATE OR REPLACE VIEW : "The new query must generate the same columns that were generated by the existing view query (that is, the same column names in the same order and with the *same data types*), but it may add additional columns to the end of the list. *The calculations giving rise to the output columns may be completely different*." It doesn't say wether the COLLATION is considered being part of the "data types" or not, i.e. it doesn't say wether it's possible to change the COLLATION of an existing field or not. My tests (under Postgres v. 12.4) showed that the COLLATION of an existing field can not be changed : trying to do so, postgres says nothing and seems to accept the SQL statement, but nothing is changed in the database (it silently fails). From the user perspective, I consider such a silent failure the WORST situation possible : I would prefer either 1) to get an error message saying that it's not possible to change the COLLATION of an existing field - OR even better - 2) to actually change the COLLATION of the existing field, as requested. For this reason, I'm also filling a bug report, since postgresql's reaction was not adapted to my request (neither an appropriate error message nor successful execution of my SQL statement).
Re: Doc says nothing about wether CREATE OR REPLACE VIEW can change the COLLATION of an existing field
От
"David G. Johnston"
Дата:
On Tue, Feb 15, 2022 at 8:04 AM PG Doc comments form <noreply@postgresql.org> wrote:
For this reason, I'm also filling a bug report, since postgresql's reaction
was not adapted to my request (neither an appropriate error message nor
successful execution of my SQL statement).
The bug report is valid and sufficient. We really don't want to have two threads active discussing the issue.
David J.