Thomas Hallgren wrote:
Some very good suggestions where made here. What happens next? Will this end
up in a TODO list where someone can "claim the task" (I'm trying to learn
how the process works) ?
If someone doesn't jump right on it and make a "diff -c" proposal, it
probably belongs on the TODO
Lane" <[EMAIL PROTECTED]>;
"Peter Eisentraut" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, February 20, 2004 04:39
Subject: Re: [HACKERS] Advice regarding configuration parameters
> Thomas Hallgren wrote:
> > No, this was not related to trigger
PROTECTED]>
To: "Joe Conway" <[EMAIL PROTECTED]>
Cc: "Peter Eisentraut" <[EMAIL PROTECTED]>; "Thomas Hallgren"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, February 06, 2004 19:15
Subject: Re: [HACKERS] Advice regarding configuration para
Tom Lane wrote:
The sort of semantic funny I am thinking of is like this:
* postgresql.conf contains pljava::var = somegoodvalue
* ALTER DATABASE SET supplies pljava::var = somebadvalue
For builtin variables the ALTER DATABASE value would be rejected on
sight and the end result would be that the va
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> I have been thinking for some time about a generic mechanism to
>> configure procedural languages. It could be a text array in
>> pg_language that you could fill at will.
> One big question is whether the per-language variable
Patch posted on the patches list :-)
Let me know what you think.
- thomas
"Joe Conway" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Thomas Hallgren wrote:
> > Some very good suggestions where made here. What happens next? Will this
end
> > up in a TODO list where someone can "cl
uot; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Friday, February 20, 2004 04:39
> Subject: Re: [HACKERS] Advice regarding configuration parameters
>
>
> > Thomas Hallgren wrote:
> > > No, this was not related to triggers at all. The original discussion
Lane" <[EMAIL PROTECTED]>;
"Peter Eisentraut" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, February 20, 2004 04:39
Subject: Re: [HACKERS] Advice regarding configuration parameters
> Thomas Hallgren wrote:
> > No, this was not related to trigger
Thomas Hallgren wrote:
> No, this was not related to triggers at all. The original discussion
> concerned GUC functionality to handle configuration settings for pl
> extensions.
OK. If you guys agree on TODO wording, I will add it.
--
Bruce Momjian| http://candle.pha.
t;
Cc: "Thomas Hallgren" <[EMAIL PROTECTED]>; "Tom Lane"
<[EMAIL PROTECTED]>; "Peter Eisentraut" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Thursday, February 19, 2004 21:00
Subject: Re: [HACKERS] Advice regarding configuration parameters
Joe Conway wrote:
> Thomas Hallgren wrote:
> > Some very good suggestions where made here. What happens next? Will this end
> > up in a TODO list where someone can "claim the task" (I'm trying to learn
> > how the process works) ?
>
> If someone doesn't jump right on it and make a "diff -c" propos
Thomas Hallgren wrote:
Some very good suggestions where made here. What happens next? Will this end
up in a TODO list where someone can "claim the task" (I'm trying to learn
how the process works) ?
If someone doesn't jump right on it and make a "diff -c" proposal, it
probably belongs on the TODO
On 02/06/04:05/5, Tom Lane wrote:
> To: Joe Conway <[EMAIL PROTECTED]>
> Cc: Peter Eisentraut <[EMAIL PROTECTED]>,
> Thomas Hallgren <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Advice regarding configuration parameters
> D
Tom Lane wrote:
> Given all the work Peter put into GUC (for very good reasons), I was
> a tad astonished to read him proposing to develop a non-GUC mechanism
> for configuring PLs.
I for one was a tad astonished to read that there is already support for
adding variables at run-time, given that w
Peter Eisentraut wrote:
> Am Freitag, 6. Februar 2004 10:27 schrieb Thomas Hallgren:
> > I would like some configuration parameters to Pl/Java and I would like some
> > advice. Where should they go?
> >
> > 1. Something similar to postgresql.conf (it's not extendable though, is
> > it?)
>
> No, it
Joe Conway <[EMAIL PROTECTED]> writes:
> I like it. I wonder if we ought to have a way to "register" valid
> classes? Maybe a new guc variable in the form of a list of valid
> classes. So something like:
There are some order-of-processing issues there, but maybe. Another
possibility is that after
Tom Lane wrote:
What do you think of the idea of suppressing the "unknown variable"
error for some class of variable names?
I like it. I wonder if we ought to have a way to "register" valid
classes? Maybe a new guc variable in the form of a list of valid
classes. So something like:
custom_variable
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Am Freitag, 6. Februar 2004 10:27 schrieb Thomas Hallgren:
1. Something similar to postgresql.conf (it's not extendable though, is
it?)
No, it is not.
In principle it could be --- the mechanisms already exist in guc.c to
permit outside a
Joe Conway <[EMAIL PROTECTED]> writes:
> I still think it is a good idea and that
> the difficulties can be worked out.
What do you think of the idea of suppressing the "unknown variable"
error for some class of variable names?
If we had agreement on doing that then I think the rest would be pre
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 6. Februar 2004 10:27 schrieb Thomas Hallgren:
>> I would like some configuration parameters to Pl/Java and I would like some
>> advice. Where should they go?
>>
>> 1. Something similar to postgresql.conf (it's not extendable though, is
>>
Am Freitag, 6. Februar 2004 10:27 schrieb Thomas Hallgren:
> I would like some configuration parameters to Pl/Java and I would like some
> advice. Where should they go?
>
> 1. Something similar to postgresql.conf (it's not extendable though, is
> it?)
No, it is not.
> 2. A Table in the database i
I would like some configuration parameters to Pl/Java and I would like some
advice. Where should they go?
1. Something similar to postgresql.conf (it's not extendable though, is it?)
2. A Table in the database in the "sqlj" schema
3. Java properties file (cumbersome, must be available prior to sta
22 matches
Mail list logo
