> Clinging to sanity, pgsql@mohawksoft.com ("Mark Woodward") mumbled into
> her beard:
>> What is the point of writing a proposal if there is a threat of
>> "will be rejected" if one of the people who would do the rejection
>> doesn't at least outline what would be acceptable?
>
> If your proposal is merely "let's do something like Oracle," it should
> be obvious why that would be rejected. There is considerable legal
> danger to slavish emulation. Further, since PostgreSQL isn't Oracle,
> slavish emulation wouldn't work anyways.
I don't actually like Oracle's hinting system.
>
> If a proposal is too fuzzy to be considered a source of a
> specification, it should be obvious that that would be rejected.
Well, "fuzzy" isn't a bad starting place to start gathering information
for an eventual proposal.
>
> If you have an idea clear enough to turn into a meaningful proposal,
> put it in for the usual "to and fro"; that generally leads to enormous
> improvements.
Absolutely.
>
> I'm not sure what a good hinting system ought to look like; what I
> *do* know is that a fuzzy proposal won't be much good.
That is sort of the stopping block. None of us "know" what it should look
like, but leaving the topic as "if you want it, go do the work and submit
a patch." Isn't going to get it done.
First we should decide if it is, in fact, something that ought to happen,
then if that happens, we should think about what it should be.
Again, what would be the point of writing a proposal if there is *no*
concensus on what would be acceptible?
