>>> 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
