Re: NUMERIC private methods?
От
David Fetter
Тема
Re: NUMERIC private methods?
Дата
Msg-id
20141219174454.GA6891@fetter.org
Ответ на
Re: NUMERIC private methods? (Alvaro Herrera)
Список
Дерево обсуждения
NUMERIC private methods? David Fetter <david@fetter.org>
Re: NUMERIC private methods? Heikki Linnakangas <hlinnakangas@vmware.com>
Re: NUMERIC private methods? Tom Lane <tgl@sss.pgh.pa.us>
Re: NUMERIC private methods? Andrew Gierth <andrew@tao11.riddles.org.uk>
Re: NUMERIC private methods? Tom Lane <tgl@sss.pgh.pa.us>
Re: NUMERIC private methods? Jim Nasby <Jim.Nasby@BlueTreble.com>
Re: NUMERIC private methods? Robert Haas <robertmhaas@gmail.com>
Re: NUMERIC private methods? Tom Lane <tgl@sss.pgh.pa.us>
Re: NUMERIC private methods? Bruce Momjian <bruce@momjian.us>
Re: NUMERIC private methods? Andrew Gierth <andrew@tao11.riddles.org.uk>
Re: NUMERIC private methods? Bruce Momjian <bruce@momjian.us>
Re: NUMERIC private methods? Robert Haas <robertmhaas@gmail.com>
Re: NUMERIC private methods? Tom Lane <tgl@sss.pgh.pa.us>
Re: NUMERIC private methods? Robert Haas <robertmhaas@gmail.com>
Re: NUMERIC private methods? Alvaro Herrera <alvherre@2ndquadrant.com>
Re: NUMERIC private methods? David Fetter <david@fetter.org>
Re: NUMERIC private methods? Andrew Gierth <andrew@tao11.riddles.org.uk>
Re: NUMERIC private methods? David Fetter <david@fetter.org>
On Thu, Dec 18, 2014 at 11:51:37PM -0300, Alvaro Herrera wrote: > Robert Haas wrote: > > > I think that's ridiculous. You're basically arguing that numeric > > doesn't offer meaningful advantages over float8, which flies in > > the face of the fact that essentially every database application > > I've ever seen uses numeric and I'm not sure I've ever seen one > > using float8. Nearly all database users prefer to store > > quantities like currency units in a type that is guaranteed not to > > lose precision. > > I think it's reasonable to expose NumericVar and the supporting > function prototypes in, say, numeric_internal.h; normal applications > that just want to operate on numerics as today can just include > numeric.h, and continue to be at arms-length of the implementation > details, while code that wants to optimize operations further can > use numeric_internal.h and be very aware that they are subject to > heavy breakage if we ever feel a need to change the internal API. While nothing can prevent negligence and pilot error, making it clear by the name of the included header that breakable stuff is being used seems like an excellent way to proceed. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
В списке pgsql-hackers по дате отправления