>> > 2) Why would allowing one or both of the Bigs prevent Number from being >> > allowed as a serializable type? >> > >> Not sure I said that. The problem is that if something is potentially >> Big... then a database must be prepared to deal with it and it has a >> high cost. > > > > Every Puppet value is potentially a Big now. What new cost is involved? > I'm having trouble seeing how a database can deal efficiently with Puppet's > current implicit typing anyway, Big values notwithstanding. Without > additional type information, it must be prepared for any given value to be a > boolean, an Integer, a float, or a 37kb string (among other possibilities). > Why do Big values present an especial problem in that regard?
So right now, we have alternating native postgresql columns for the bare types: text, biginteger, boolean, double precision. This provides us with the ability to use the most optimal index for the type, and of course avoid storing any more then we need to. As I mentioned at the top of the thread, we specifically do not support arbitrary precision decimals. At least one example in PostgreSQL, once you jump to say, a numeric column type the performance characteristics and index efficiency changes for the worse. Same goes for floats being stored in a numeric. This is why you are better off avoiding the conversion until you overflow and absolutely need a decimal usually. ken. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAE4bNTngnVLb9Fxhbr4MBKee8sfyqLviua%2BgWWiS6q2H4eiBng%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
