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
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.
---
Jo
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: src/backend/utils
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
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 m
Is there a new version of this patch being worked on?
---
Tom Lane wrote:
> 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,
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 fo
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
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 tel
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 diffe
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
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) through
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
> cur
Peter Eisentraut wrote:
> 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 so
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
Joachim Wieland wrote:
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 an
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
> DefineCusto
"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. T
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
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 worked on this
issue, the old behavior wa
"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 appl
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. T
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
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, ov
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.
---
Jo
25 matches
Mail list logo
