Stephen Frost <sfr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers