Re: guc comment changes (was Re: [HACKERS] Getting a move on for 8.2
Tom Lane wrote: Peter Eisentraut <[EMAIL PROTECTED]> writes: That does not mean that the patch is bad, and I certainly support the feature change. But I can't efficiently review the patch. If someone else wants to do it, go ahead. I've finally taken a close look at this patch, and I don't like it any more than Peter does. The refactoring might or might not be good at its core, but as presented it is horrid. As just one example, it replaces one reasonably well-commented function with three misnamed, poorly commented functions. In place of Thanks Tom for your time to look on the code and for your feedback. It is very useful for me. Thanks Zdenek ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: guc comment changes (was Re: [HACKERS] Getting a move on for 8.2 beta)
Joachim Wieland <[EMAIL PROTECTED]> writes: > I have the patch almost ready in the described form, if there is any chance > it will make it into 8.2 I will clean it up and post it ASAP but Peter wrote > me that chances are close to zero and so I stopped working on it for now. If you'd mentioned it a bit sooner I would have encouraged you to get it done. But given your description it sounds a bit too hairy/potentially-destabilizing to be dropping in the day before beta. (I certainly hadn't thought about custom vars at all :-() Let's plan it for 8.3 instead. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: guc comment changes (was Re: [HACKERS] Getting a move on for 8.2 beta)
On Mon, Sep 18, 2006 at 01:13:45PM +0200, Peter Eisentraut wrote: > Joachim Wieland is in the process of reworking the original feature patch > (resetting commented out parameters) in a much more compact form. But it > turns out that there are a couple of very tricky situations involving custom > variables, which may need more discussion than we have time for now. The problem with custom variables is the definition of their default value. First I defined it to be "variable does not exist" and tried to have a close analogy to what happens on set/set local/reset with normal variables. However that means that custom variables have to vanish (where other variables show their default value) and revive (where other variables show a changed value). For example if you have: begin; savepoint a; set foo.var to 3; (here we delete foo.var from the configuration file and send SIGHUP) savepoint b; reset foo.var; There seem to exist quite a few possible definitions as to what happens if you run "show foo.var" after the "reset" directly or after rolling back to the savepoints a and b. The result of the discussion with Peter was that all that seems not worth doing since it is a rare special case. In the current form of the patch if you delete a custom variable from the configuration file it gets deleted internally and all reference to it results in error. There is still one special case which is: begin; set foo.var to 3; (here we delete foo.var from the configuration file and send SIGHUP) commit; This transaction will fail because commit cannot change the value of the variable to 3 as requested by the user. I have the patch almost ready in the described form, if there is any chance it will make it into 8.2 I will clean it up and post it ASAP but Peter wrote me that chances are close to zero and so I stopped working on it for now. Joachim -- Joachim Wieland [EMAIL PROTECTED] GPG key available ---(end of broadcast)--- TIP 1: 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
Re: guc comment changes (was Re: [HACKERS] Getting a move on for 8.2 beta)
Am Freitag, 15. September 2006 20:32 schrieb Tom Lane: > I've finally taken a close look at this patch, and I don't like it any > more than Peter does. The refactoring might or might not be good at its > core, but as presented it is horrid. Joachim Wieland is in the process of reworking the original feature patch (resetting commented out parameters) in a much more compact form. But it turns out that there are a couple of very tricky situations involving custom variables, which may need more discussion than we have time for now. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
