On Sat, Apr 4, 2009 at 11:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sat, Apr 4, 2009 at 7:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I'm not thrilled about adding a column to pg_attribute for this. > >> What is the specific nature of your concern? > > Actually, I'm more worried about the TupleDesc data structure than > the catalogs. There are TupleDescs all over the backend, and I've > seen evidence in profiles that setting them up is a nontrivial cost. > > You're very possibly right that four more bytes is in the noise, > though. > > Two other comments now that I've read a little further: > > * This isn't happening for 8.4, so adjust the pg_dump code.
I thought about writing 80500, but the effect of that would have been to render the patch impossible to test, so I didn't. :-) I think I'll be very lucky if that's the most bitrot this accumulates between now and when the tree is open for 8.5 development. System catalog changes stink in that regard. I suppose we could tag and branch the tree now, but that would just move the work of fixing any subsequent conflicts from patch authors to committers, which is sort of a zero-sum game. > * Using an integer is bogus. Use a float4 and forget the weird scaling; > it should have exactly the same interpretation as stadistinct, except > for 0 meaning "unset" instead of "unknown". I think there's a pretty good chance that will lead to a complaint that is some variant of the following: "I ran this command and then I did a pg_dump and the output doesn't match what I put in." Or maybe, "I did a dump and a restore on a different machine with a different architecture and then another dump and then I diffed them and this popped out." I have a deep-seated aversion to storing important values as float, and we seem to have no other floats anywhere in our DDL, so I was a little leery about breaking new ground. There's nothing particularly special about the scaling that the pg_statistic stuff uses, and it's basically pretty obscure internal stuff anyway, so I think the consistency argument is fairly weak. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
