On Jun 8, 2011, at 5:36 PM, Brar Piening wrote: > Pros > Mike Pultz (patch author): "since serial4 and serial8 are simply > pseudo-types- effectively there for convenience, I’d argue that it should > simply be there for completeness" > Robert Haas: "We should be trying to put all types on equal footing, rather > than artificially privilege some over others." > Brar Piening (me): "I'm with the above arguments. In addition I'd like to > mention that other databases have it too so having it improves portability. > Especially when using ORM." > Perhaps we can get some more opinions...
We have some "dynamic lookup table" metacode that sets up all the infrastructure for a table that normalizes text values to a serial/int. But in many cases, it's a safe bet that we would never need more than 32k (or at worst, 64k) values. Right now it would be difficult to benefit from the 2 byte savings, but if Postgres was ever able to order fields on disk in the most efficient possible format (something we're willing to sponsor, hint hint ;) then this would be beneficial for us. -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
