Re: effective SELECT from child tables
От | Andrew Dunstan |
---|---|
Тема | Re: effective SELECT from child tables |
Дата | |
Msg-id | 433EB528.1000005@dunslane.net обсуждение исходный текст |
Ответ на | Re: effective SELECT from child tables ("Jim C. Nasby" <jnasby@pervasive.com>) |
Список | pgsql-hackers |
Jim C. Nasby wrote: >On Sat, Oct 01, 2005 at 02:13:09PM +0200, Martijn van Oosterhout wrote: > > >>On Fri, Sep 30, 2005 at 06:30:10PM -0500, Jim C. Nasby wrote: >> >> >>>On Wed, Sep 28, 2005 at 07:25:46PM +0100, Simon Riggs wrote: >>> >>> >>>>Include the Discriminator as a column in A and it will be inherited by >>>>all A1, A2, A3. >>>>e.g. concrete_class char(1) not null >>>> >>>> >>><snip> >>> >>> >>>>This will add 1 byte per row in your superclass... and requires no >>>> >>>> >>>I thought char was actually stored variable-length...? I know there's a >>>type that actually acts like char does on most databases, but I can't >>>remember what it is off-hand (it should be mentioned in docs 8.3...) >>> >>> >>IIRC, this is the difference between "char" and char(1). The latter is >>variable length and can store any character per current encoding, hence >>the variable length. "char" on the other hand is a one byte (presumably >>ASCII) character. It's used mainly in the system catalogs... >> >> > >According to the docs, char == char(1). > > The docs also say: The type "char" (note the quotes) is different from char(1) in that it only uses one byte of storage. It is internally used in the system catalogs as a poor-man's enumeration type. cheers andrew
В списке pgsql-hackers по дате отправления: