AW: [HACKERS] Re: atttypmod of 0
От | Zeugswetter Andreas DBT |
---|---|
Тема | AW: [HACKERS] Re: atttypmod of 0 |
Дата | |
Msg-id | 219F68D65015D011A8E000006F8590C6010A51BC@sdexcsrv1.sd.spardat.at обсуждение исходный текст |
Ответы |
Re: AW: [HACKERS] Re: atttypmod of 0
Re: AW: [HACKERS] Re: atttypmod of 0 |
Список | pgsql-hackers |
Yes, I think to change atttypmod to default to -1 would be the right thing, since the empty string '' really has a length of 0, We could think of -1 as: We don't know how long this field will be. 0 would mean the field has 0 bytes. Andreas > > > > This time it's during the parser (gdb told me). varcharin() > > is called with a atttypmod of 0 causing a palloc() of 0 > > bytes. How should a VARCHAR type whithout a specified length > > behave? Is this type 1 character or a variable size up to > > 4096? > > > > I thought we fixed this on Feb 3. look at > > parse_expr.c line 104: it should read: > > if (con->typename != NULL) > > ! result = > parser_typecast(val, > > con->typename, -1); > > else > > > > I think all funcs calling with atttypmod = 0 are allways wrong, > should > > be -1. > > or a number > 0 (or 4 if atttypmod includes the VARHDRSZ don't know) > > > > > Andreas > > > > > > Yes, we did, but now I fixed varcharin, and bpcharin to test for > atttypmod of 0 and do the right thing, I think. If we need to make > the > default atttypmod value -1, then we can change it back. Let me know > if > the current fix does not work. > > Should I make atttypmod default to -1? > > -- > Bruce Momjian > maillist@candle.pha.pa.us > >
В списке pgsql-hackers по дате отправления: