Re: Deprecating RULES - Mailing list pgsql-hackers

On Wed, Oct 17, 2012 at 1:12 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 10/17/12 12:57 PM, Daniel Farina wrote:
>> I'll have to register my disagreement then, in the special case where
>> a feature becomes so obscure that many people don't have a wide-spread
>> intuition at what it's good at or used for.  Tom also said "build the
>> replacement," and without itemization of use cases, I don't even know
>> what that would look like -- perhaps such knowledge is assumed, but I
>> think it's assumed wrongly, so perhaps there just needs to be some
>> education.  At best you could define what to build somewhat
>> tautologically from the mechanism used by RULES, and that's not a very
>> good way to go about it, methinks.

[use case, redacted, although worth independent consideration]

> Putting it as "Andrew and Josh need to enumerate these cases, or forever
> be silent" is quite unfair to our users.  Andrew and I hardly represent
> the entire scope of PostgreSQL app developers.  Enumerating the cases,
> finding replacements for them, and documenting migrations needs to be a
> group effort.

Unfortunately I myself see little evidence of the vast, vast --
several nines of vast -- majority of folks using rules, and as I said:
as a thought experiment, merely one solved bug is worth more to me
than rules from what I know at this time.  If I had a wealth of user
pain to draw upon, I would have in opposition to their deprecation.
But, I don't, so I am cautiously in favor of pipelining a slow
deprecation, even though I can only be hurt by the process tactically
-- strategically, I can be helped, e.g. by solving even one defect
that lowers *my* maintenance cost.  You can consider my sentiment the
result of some evidence of absence, if you will.  I can probably
refine this intuition if it would change someone's mind, but given the
tone of conversation, I'd probably simply be given a no-true-scotsman
retort -- which is true, Heroku's user base is not provably
representative of all users.  But what else is there to go on, besides
experiences of others, such as yours and Andrew's, or others?

Both of you have given some well-considered use cases now, but the
conversation was a quagmire a while because it seems like the thing to
do was dismiss those charitable to the idea of deprecation rather than
even tersely list out use cases that are in danger.  If the project
suffered a vast number of deprecation requests I could understand the
'silence is not consent' argument, because who has the time to defend
all territory all the time?  But as-is such conversations are so rare
that I think positive identification of use cases is worthwhile use of
time, if it can result in but a chance of eliminating maintenance
burden and surface area.

Features do not stay for free, especially not at the level of quality
the project demands, and my personal sanity benefits from that
quality.  While nobody has given a cost of the maintenance of rules, I
would surmise it is non-zero, and consuming resources on potentially
lousy features is not a service to users either, and I do not wish
that to be ignored.

Finally, putting aside the use cases you are able to positively
identify from your personal experirence, I think it's reasonable to
put in a message of intent-to-deprecate and reverse or revise course
as more data appears.  Perhaps the thinking should be: "intent to
aggressively gather data to enable deprecation" rather than "a final
deprecation decision and plan, full stop."  The most direct route may
be to package such a request into error messages or warnings in the
database, because I do not think release notes or announcements are
enough.

Contrast this with the sudden change to VACUUM FULL: from no doubling
in space usage to a doubling in space usage temporarily.  That's
nothing to sneeze at, and who knows, thousands of administrative
scripts happily VACUUM FULLing could have blown up terribly.  But, it
was changed anyway, because the feature was pretty much deemed not
that useful to people relating their needs.  How is this reasoning
consistent with that change?

--
fdr