The following bug has been logged online:

Bug reference: 2802
Logged by: Albert Strasheim
Email address: fullung (AT) gmail (DOT) com
PostgreSQL version: 8.1
Operating system: Windows
Description: Feature request: tinyint and unsigned types
Details:

MySQL's support for 1-byte integers and unsigned types are very useful in
some applications where it makes sense to express certain values as 1-byte
values or as unsigned values. Having support for this in PostgreSQL would be
awesome.

Yes, bigger types can be used, but they introduce additional storage
requirements that maybe be excessive in certain situations.

http://dev.mysql.com/doc/refman/5.0/...ric-types.html

Thanks!

Cheers,

Albert Strasheim

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

On Fri, Dec 01, 2006 at 20:41:32 +0000,
Albert Strasheim <fullung (AT) gmail (DOT) com> wrote:
You can already use "char" to store 1 byte values, though unless there are
several of these in a row, you won't save any space because of alignment.

There are also people working on a nicer way to do enum, that looked to
be relatively space efficient (though I don't remember if there was going
to be a way to store small sets using only one byte). This got discussed
a while ago, but didn't make it into 8.2 (as far as I can tell).

Depending on what you are really trying to do, bit strings may also be
useful for you. While individual bit string columns aren't going to fit
in one byte, you can pack bits together which might be a saving over all.

Postgres is extensible, so you can add your one 1 byte types without
doing too much work.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Dec 4, 2006, at 4:11 PM, Bruno Wolff III wrote:
<nitpick>There's also boolean...</nitpick>

Is there any technical reason why we don't support unsigned ints or
tinyint? Just a matter of no one feeling the itch?
--
Jim Nasby jim (AT) nasby (DOT) net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Jim Nasby <decibel (AT) decibel (DOT) org> writes:
The question is whether it's worth complicating the numeric-type
promotion hierarchy even more. A variant int type probably isn't worth
much if it doesn't interact naturally with arithmetic & comparisons with
other int types, but we've found out the hard way that you can't have a
huge number of possible interpretations, or you get too many "can't
resolve which operator to use" errors. (See the archives for details.)

My private suspicion is that 90% of the people who say they want tinyint
are really looking for a enum type, and thus that Tom Dunstan's recent
patch for enum support might solve their problem. (Did Tom's patch
allow for the storage size to vary depending on the number of values?
Those folk won't be satisfied if not, even though we all know that
alignment issues frequently negate any savings...)

As for unsigned, you can use OID as uint4 if you must.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Hello all,

Firstly, thanks for taking the time to evaluate my request.

On Sat, 09 Dec 2006, Tom Lane wrote:

Agreed. Some variables I had wanted to make tinyints could be expressed
as enumerated values. Other variables I wanted to express as unsigned
ints or tinyints or unsigned tinyints to model the possible values
from the problem domain as succinctly as possible.

I wasn't aware of alignment issues negating the savings I was hoping to
achieve. A discussion in the data types section of the user manual
about alignment issues as would have set me straight.

Agreed. I could also use chars for 1-byte values, but my data really are
numbers, not characters. Again, I was trying to write a schema that
models the problem domain as accurately as possible, data types and
all. I'm guessing here, but using "incorrect" data types probably runs
you into an interesting set of problems when you start accessing your
database through JDBC or higher level things like an ORM library. Now
you have to explain to this library that, while your schema says char,
you really meant unsigned tinyint.

Thanks for everyone's inputs.

Regards,

Albert Strasheim

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Albert Strasheim wrote:
Then use domains.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

--423qzgGQ+XtHwwVq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Peter Eisentraut (peter_e (AT) gmx (DOT) net) wrote:
Or constraints...

Stephen

--423qzgGQ+XtHwwVq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFfHiXrzgMPqB3kigRAi8fAJ9HIhs1NX/4MSZLYJ8yz8aQ9H/U5wCePi4e
CAAD/eEMP7Wbx+ll8a0qKL8=
=5BrX
-----END PGP SIGNATURE-----

--423qzgGQ+XtHwwVq--