Re: Is there a reason why Postgres doesn't have Byte or tinyint?

On Sun, Jan 8, 2012 at 12:35 AM, Darren Duncan <darren(at)darrenduncan(dot)net> wrote:
> Mike Christensen wrote:
>>>>
>>>> According to the manuals, Postgres has smallint (2 byte), integer (4
>>>> bytes) and bigint (8 bytes)..  I use a lot of structures with "bytes"
>>>> in my code and it's kinda annoying to cast DB output from Int16 to
>>>> Byte every time, especially since there's no explicit cast in .NET and
>>>> you have to use System.Convert().
>>>>
>>>> Is there a work-around, or do people just cast or use Int16 in their
>>>> data structures?  Just wondering..  I know on modern computers it
>>>> probably doesn't make any difference anyway..
>>>
>>>
>>> Is this just about programmer convenience or is it about space efficiency
>>> in
>>> the database?  BYTEA might help you.  Or try declaring a DOMAIN over
>>> SMALLINT that limits allowed values to the range of a byte. -- Darren
>>> Duncan
>>
>>
>> This is purely programmer convenience.
>>
>> Basically, I want Npgsql to marshal the value as a .NET Byte type, if
>> I can find a way to do that I'm happy.  Perhaps it's more of a Npgsql
>> question, though I'm curious as to why Postgres doesn't have an
>> intrinsic tinyint or byte type.
>
>
> Maybe Postgres doesn't need a Byte type predefined because it gives you the
> means to define the type yourself, such as using DOMAIN.
>
> Generally speaking, I believe it is more important for a type system to
> provide the means for arbitrary user-defined types which can be used in all
> the places as built-in-defined types, than to have large numbers of
> built-in-defined types.

Precisely. postgresql's extensable nature allows you to build your
own types as well. If it's popular enough it'll make it into contrib,
then maybe core. My guess is that there's some non-trivial cost to
maintaining each core type, and since a byte type isn't required by
the SQL spec, it would take some effort to get a standard one included
in the core.