Marc G. Fournier wrote:
> > However, if you don't accept voting as a valid way to determine if a
> > patch is acceptible, what method do you suggest? I don't think we want
> > to go down the road of saying that you can't vote "no" on a feature
> > addition.
> >
> > We just rejected a patch today on LIMIT with UPDATE/DELETE via an
> > informal vote, and I think it was a valid rejection.
>
> Its not the concept of 'the vote', its what is being voted on that I have
> a major problem with ... for instance, with the above LIMIT patch ... you
> are talking about functionality ... I haven't seen that thread yet, so am
> not sure why it was rejected, but did the submitter agree with the
> reasons? Assuming he did, is this something he's going to re-submit later
> after makign fixes?
>
> See, that is one thing I have enjoyed over the years ... someone submit's
> a patch and a few ppl jump on top of it, point out a few problems iwth it
> and the submitter re-submits with appropriate fixes ...
>
> Actually, I just went to my -patches folder and read the thread ... first
> off, the 'informal vote' appears to have consisted of Tom Lane and Alvaro
> Herrera, which isn't a vote ... second of all, in that case, the
> implementation of such, I believe, would go against SQL specs, no? Second
> of all, doesn't it just purely go against the point of a RDBMS if there
> are multiple rows in a table with nothing to identify them except for the
> ctid/oid? *scratch head*
>
> My point is, the use of an ENVIRONMENT variable for pointing ot a
> directory is nowhere near on the scale of implementing an SQL statement
> (or extension) that serves to take us steps backwards against the progress
> we've made to improve our compliance ...
The issue isn't really compliance because LIMIT in SELECT isn't
compliant either, so adding it to UPDATE/DELETE is just as non-standard
as in SELECT. The real question we vote on, I think, is, "Should this
feature be given to our users? What value does it provide, and what
confusion does it cause? Does the standard suggest anything?"
I think that is the usual criteria. For LIMIT on UPDATE/DELETE, it
provides little value, and adds confusion, i.e. an extra clause in those two
commands that really doesn't add any functionality.
Now, for the PG_XLOG environment variable/-X flag, it is almost the same
result, i.e. it doesn't add much value (use a symlink) and does add
confusion (oops, I forgot to set it).
The idea of having the pg_xlog location in GUC I think was a good
compromise, but too late to be discovered. If the patch author had
continued discussion at the time, I think it would be in 7.3.
> one has been removed due to personal preferences and nothign else ... the
> other rejected as it will break (unless I've misread things?) standard,
> accepted procedures ...
PG_XLOG was remove for a few reasons:
It didn't add much functionality
It was ugly to add -X to all those commands
It was error-prone
Again, the same criteria. Are you saying the criteria I mentioned above
is wrong?
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
