Stephen Frost <sfrost@snowman.net> writes:
> If we take your approach to its logical conclustion then we should be
> planning to maintain all user-facing deprecated features for as long as
> there is a version where it exists in a non-deprecated fashion, in other
> words for 5 years, if we assume that script authors only care about
> supporting as far back as we do, which I'm not entirely sure is a great
> assumption to begin with, but I'd say it's at least a minimum.
Well, that is definitely a straw man (as you admit later). I don't want
to go there either. Where to draw the line has to be a case-by-case
decision, though. In this case the amount of effort involved in providing
backwards compatibility is pretty minimal, and the project has failed to
provide any warning to users that this is something we might choose to
break in future, so it seems to me that we ought to provide compatibility
for awhile. If somebody bitches that we broke their script in v15, we'll
be in a much better position if we can point to five years' worth of
deprecation notices than if we just have to say "tough, we felt like
breaking your script so we did it".
> I'll admit that part of that is likely because I don't think I have
> *ever* used createdb or createlang or createuser (excepting whatever
> regression tests run them),
Well, personally I use createdb pretty often. I basically never use
the other two, but I don't fool myself that I'm a representative user.
createuser in particular seems like it has pretty high value-added
if you create new roles often and need to give them passwords. Yeah,
you can do it in psql, but it's not as convenient, especially if you
want to do proper quoting.
regards, tom lane
