Re: [HACKERS] varchar() vs char16 performance
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] varchar() vs char16 performance |
Дата | |
Msg-id | 350D4171.5AF1A035@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] varchar() vs char16 performance (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] varchar() vs char16 performance
|
Список | pgsql-hackers |
> > >The char2,4,8,16 types seem to have no value-added over the > > >better-supported char(), varchar(), text types; I am considering > > >removing them from the backend, and instead have the parser > > >transparently translate the types into varchar() or char() > Maybe we just need to fix char[]. There are notes in the source code from Jolly wondering whether arrays of char/varchar would work, and specifically disallowing it "for now". imho, even though there is one user forcing arrays of single characters by invoking char2, rather than using text and substrings, that is not sufficient to keep this obsolete capability in the backend forever. There are two ways to smoothly transition to a system in which char2-16 is not a native built-in type: 1) modify the parser to automatically translate char2-16 into char(2-16). This will not allow arrays of char2. 2) put char2-16 into a user-loadable module, which could be configured into the template1 database if the installer chooses. This would retain all current char2-16 capabilities. These options are mutually exclusive, since implementing (1) would mean the parser would not allow user-defined types for (2). I had thought that char2-16 add _no_ functionality over the char() and varchar() types; Tatsuo points out at least one capability which they have. Are there any others? - Tom
В списке pgsql-hackers по дате отправления: