Re: BUG #8677: char(n) - bad limit with arrays of composite type
От | Tom Lane |
---|---|
Тема | Re: BUG #8677: char(n) - bad limit with arrays of composite type |
Дата | |
Msg-id | 18204.1386866931@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #8677: char(n) - bad limit with arrays of composite type (fabio.pasqualini@ac-reims.fr) |
Список | pgsql-bugs |
fabio.pasqualini@ac-reims.fr writes: > psql:./enseignement/bts/2014/prog_c++/carnet2/bug/test.sql:25: ERREUR: > valeur trop longue pour le type character(5) > LIGNE 2 : values ( 3,'test3', '{ "(''toto'', ''123'')", "(''titi'', '... > ^ These errors are entirely correct, because you've misunderstood the (admittedly complicated) quoting requirements for nested arrays/records in literal values. Extracting the values that you did manage to store shows the problem: # select (tab_t1)[1].cp from t2; cp ------- '1' '12' (2 rows) The quotes are being taken as data characters, and there's a leading space in there too. The rules for writing composite literals are explained here: http://www.postgresql.org/docs/9.3/static/rowtypes.html#ROWTYPES-IO-SYNTAX On the whole, it's very often easier to use ARRAY[] and ROW() constructors than to get the quoting rules right for literal syntax. I'd have done these examples like this: insert into t2(id_t2, nom, tab_t1) values ( 3,'test3',array[row('toto', '123'), row('titi', '123')]::t1[]); You need an explicit cast unfortunately, because otherwise the ARRAY[] constructor yields record[] which is not considered automatically castable to t1[]. regards, tom lane
В списке pgsql-bugs по дате отправления: