On 2013-06-12 19:47:46 +0800, Craig Ringer wrote: > On 06/12/2013 05:55 PM, Greg Stark wrote: > > On Wed, Jun 12, 2013 at 12:56 AM, Craig Ringer <cr...@2ndquadrant.com> > > wrote: > >> The main thing I'm wondering is how/if to handle backward compatibility > >> with > >> the existing NUMERIC and its DECIMAL alias > > If it were 100% functionally equivalent you could just hide the > > implementation internally. Have a bit that indicates which > > representation was stored and call the right function depending. > > That's what I was originally wondering about, but as Tom pointed out it > won't work. We'd still need to handle scale and precision greater than > that offered by _Decimal128 and wouldn't know in advance how much > scale/precision they wanted to preserve. So we'd land up upcasting > everything to NUMERIC whenever we did anything with it anyway, only to > then convert it back into the appropriate fixed size decimal type for > storage.
Well, you can limit the "upcasting" to the cases where we would exceed the precision. > Pretty pointless, and made doubly so by the fact that if we're > not using a nice fixed-width type and have to support VARLENA we miss > out on a whole bunch of performance benefits. I rather doubt that using a 1byte varlena - which it will be for reasonably sized Datums - will be a relevant bottleneck here. Maybe if you only have 'NOT NULL', fixed width columns, but even then... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
