Patch applied by Peter. Thanks.
---
Joachim Wieland wrote:
On Mon, Apr 02, 2007 at 07:25:46PM -0400, Bruce Momjian wrote:
I assume this patch is not ready for 8.3, so I added a URL to the TODO
list for it.
I have
On Mon, Apr 02, 2007 at 07:25:46PM -0400, Bruce Momjian wrote:
I assume this patch is not ready for 8.3, so I added a URL to the TODO
list for it.
I have reworked it such that it ignores custom variable templates as Tom
suggested. Attached is the new version.
Joachim
Index:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
I assume this patch is not ready for 8.3, so I added a URL to the TODO
list for it.
---
Tom Lane wrote:
Joachim Wieland [EMAIL PROTECTED] writes:
On Tue, Mar 13, 2007 at 11:52:38AM -0400, Tom Lane wrote:
Why do you
On Thu, Mar 22, 2007 at 04:58:09PM -0400, Bruce Momjian wrote:
Is there a new version of this patch being worked on?
Yes, I will submit a new version next week.
Joachim
---(end of broadcast)---
TIP 5: don't forget to increase your free space
Peter Eisentraut [EMAIL PROTECTED] writes:
Gregory Stark wrote:
This is a pretty major user-visible change. While I'm strongly in
favour of it it seems like there ought to be some documentation file
touched by this, no? Or have I missed it?
In my opinion, and possibly that of others who have
Tom Lane [EMAIL PROTECTED] writes:
It's a release-note item ... assuming that it doesn't get reverted in
the near future. Could we have some attention to the all-red buildfarm?
It's not just a bug. There's code missing.
The code seems to assume that all custom variables are strings. There
On Tue, Mar 13, 2007 at 08:22:17AM +, Gregory Stark wrote:
The code seems to assume that all custom variables are strings. There are
about half a dozen Assert(variable-vartype == PGC_STRING) throughout the
patch. That's not true, plperl's use_strict is a boolean and we have
Gregory Stark [EMAIL PROTECTED] writes:
It's not just a bug. There's code missing.
The code seems to assume that all custom variables are strings. There are
about half a dozen Assert(variable-vartype == PGC_STRING) throughout the
patch. That's not true, plperl's use_strict is a boolean and
Tom Lane wrote:
The thing that I was wondering about is the same Joachim mentioned:
how is it that the regression test ever worked? The answer is that
it's not really testing custom variables, because it doesn't try to
set plperl.use_strict until after plperl has been loaded into the
current
On Tue, Mar 13, 2007 at 10:19:54AM -0400, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
It's not just a bug. There's code missing.
The code seems to assume that all custom variables are strings. There are
about half a dozen Assert(variable-vartype == PGC_STRING) throughout the
Joachim Wieland [EMAIL PROTECTED] writes:
On Tue, Mar 13, 2007 at 10:19:54AM -0400, Tom Lane wrote:
Well, they *are* strings as long as they're custom. Once a
DefineCustomFoo has been executed, there (should be) no difference
between a custom variable and a hard-wired one.
The code in
On Tue, Mar 13, 2007 at 11:08:52AM -0400, Tom Lane wrote:
Joachim Wieland [EMAIL PROTECTED] writes:
On Tue, Mar 13, 2007 at 10:19:54AM -0400, Tom Lane wrote:
Well, they *are* strings as long as they're custom. Once a
DefineCustomFoo has been executed, there (should be) no difference
Joachim Wieland [EMAIL PROTECTED] writes:
On Tue, Mar 13, 2007 at 11:08:52AM -0400, Tom Lane wrote:
My point here that you shouldn't be using var-group to make any
semantic choices. That's supposed to be a label for user convenience,
nothing else.
Then what is the criterion to tell what is
On Tue, Mar 13, 2007 at 11:52:38AM -0400, Tom Lane wrote:
Then what is the criterion to tell what is a custom variable and what isn't?
Why do you need to tell that? IMHO, once the DefineCustomFoo function
has been executed, it should be exactly like any other variable (other
than having a
Joachim Wieland [EMAIL PROTECTED] writes:
On Tue, Mar 13, 2007 at 11:52:38AM -0400, Tom Lane wrote:
Why do you need to tell that? IMHO, once the DefineCustomFoo function
has been executed, it should be exactly like any other variable (other
than having a funny name).
For example for the
Joachim Wieland wrote:
Attached is the long-awaited guc patch that makes values fall back to
their default values when they got removed (or commented) from the
configuration file. This has always been a source of confusion.
I have applied your patch with some of the discussed corrections. The
Peter Eisentraut [EMAIL PROTECTED] writes:
Joachim Wieland wrote:
Attached is the long-awaited guc patch that makes values fall back to
their default values when they got removed (or commented) from the
configuration file. This has always been a source of confusion.
I have applied your
Joachim Wieland wrote:
Attached is the long-awaited guc patch that makes values fall back to
their default values when they got removed (or commented) from the
configuration file. This has always been a source of confusion.
This patch makes, in its source code comments and error messages,
On Sat, Mar 10, 2007 at 09:35:38PM +0100, Peter Eisentraut wrote:
This patch makes, in its source code comments and error messages, overly
enthusiastic references to the fact that a parameter setting was
supposedly commented. The only information that is really available,
however, is that
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Attached is the long-awaited guc patch that makes values fall back to their
default values when they got removed (or commented) from the configuration
file. This has always been a source of confusion.
There are three not-so-obvious cases that I'd like to comment:
First one:
In the configuration
22 matches
Mail list logo
