Re: PGXLOG variable worthwhile?

On Sun, 22 Sep 2002, Bruce Momjian wrote:

> Marc G. Fournier wrote:
> >
> > On Fri, 20 Sep 2002, Bruce Momjian wrote:
> >
> > > In fact, I tried to open a dialog with you on this issue several times,
> > > but when I got no reply, I had to remove PGXLOG. If we had continued
> > > discussion, we might have come up with the GUC compromise.
> >
> > Ya know, I'm sitting back and reading this, and other threads, and
> > assimilating what is being bantered about, and start to think that its
> > time to cut back on the gatekeepers ...
> >
> > Thomas implemented an option that he felt was useful, and that doesn't
> > break anything inside of the code ... he provided 2 methods of being able
> > to move the xlog's to another location (through command line and
> > environment variable, both of which are standard methods for doing such in
> > server software) ... but, because a small number of ppl "voted" that it
> > should go away, it went away ...
> >
> > You don't :vote: on stuff like this ... if you don't like it, you just
> > don't use it ... nobody is forcing you to do so. If you think there are
> > going to be idiots out here that aren't going to use it right, then you
> > document it appropriately, with *strong* wording against using it ...
>
> I understand your thought of reevaluating how we decide things.
>
> 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 ...

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 ...