Re: PGXLOG variable worthwhile? - Mailing list pgsql-hackers

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 functionalityIt was ugly to add -X to all those commandsIt was error-prone

Again, the same criteria.  Are you saying the criteria I mentioned above
is wrong?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073