On Wed, Mar 4, 2009 at 3:32 PM, Joshua D. Drake <j...@commandprompt.com> wrote: > Something that continues to grind my teeth about our software is that we > are horribly inconsistent with our system catalogs. Now I am fully and > 100% aware that changing this will break things in user land but I want > to do it anyway. In order to do that I believe we need to come up with a > very loud, extremely verbose method of communicating to people that 8.5 > *will* break things. > > It seems to me that the best method would be to follow the > information_schema naming conventions as information_schema is standard > compliant (right?). > > Thoughts?
Like everyone else who has responded to this thread, I think this is a pretty terrible idea. It's possible that there are some specific columns in some specific tables that could stand to be renamed for consistency, and perhaps if you come up with some specific proposals with careful justifications someone might support the idea of doing some limited renaming. But too much renaming is not likely to be popular with anyone for reasons that are somewhat summed up by your subject line. And, really, how much better would the new names be than the old ones anyway? The idea that a casual user will be able to query the system catalogs and gain some sort of useful information without reading the documentation or at least cracking out a couple of \d commands strikes me as a pipe dream. I'll admit that I'm a little mystified by why we use pg_class to store relations (why not pg_relation?), relnamespace to store the schema oid (why not relschema?), and so on, so some improvement is probably possible. But I'm not sure you're going to be able to come up with a name that's substantially clearer than proargmodes. Sure, you could call it argument_modes, but that's not really any clearer, it's just longer. In fact, it's my experience that exercises of this type almost always end up replacing shorter names with longer names without really making anything any better. In the end you still have to RTFM. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
