>>> This topic has been discussed before e.g. in 2008 in >>> https://www.postgresql.org/message-id/47EA5CC0.8040102%40sun.com and >>> also more recently but I cannot find it in the archives right now. > > And also before that, eg > https://www.postgresql.org/message-id/flat/199910091253.IAA10670%40candle.pha.pa.us > >> I wouldn't be opposed to this, but I would note two points on a deprecation >> cycle: >> 1 Given that people may have tools that work with all supported versions >> of PostgreSQL, this needs to be a long cycle, and >> 2. Managing that cycle makes it a little bit of a tough sell. > > If we didn't pull the trigger twenty years ago, nor ten years ago, > we're not likely to do so now. Yeah, it's a mess and we'd certainly > do it differently if we were starting from scratch, but we're not > starting from scratch. There are decades worth of scripts out there > that know these program names, most of them not under our control. > > Every time this has been looked at, we've concluded that the > distributed costs of getting rid of these program names would exceed > the value; and that tradeoff gets worse, not better, as more years > go by. I don't foresee it happening.
+1. As one of third party PostgreSQL tool developers, I am afraid changing names of PostgreSQL commands would give us lots of pain: for example checking PostgreSQL version to decide to use command "foo" not "pg_foo". Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
