On 2013-10-04 11:04:53 -0400, Robert Haas wrote:
> On Fri, Oct 4, 2013 at 10:14 AM, Andres Freund wrote:
> > But that's not a new problem? It already exists and isn't really
> > excerbated by this.
> ...
> > I agree that we could use some more infrastructure around configuration,
> > but I fail to
On Fri, Oct 4, 2013 at 10:14 AM, Andres Freund wrote:
> But that's not a new problem? It already exists and isn't really
> excerbated by this.
...
> I agree that we could use some more infrastructure around configuration,
> but I fail to understand why it's this patch's duty to deliver it. And I
>
On 2013-10-04 09:57:41 -0400, Robert Haas wrote:
> On Fri, Oct 4, 2013 at 6:06 AM, Andres Freund wrote:
> > It'd be pretty easy to have a function that removes everything inside a
> > certain namespace. That'd be enough to make EmitWarningsOnPlaceholders()
> > work, right?
>
> Maybe, but I don't
On Fri, Oct 4, 2013 at 6:06 AM, Andres Freund wrote:
> It'd be pretty easy to have a function that removes everything inside a
> certain namespace. That'd be enough to make EmitWarningsOnPlaceholders()
> work, right?
Maybe, but I don't think you're going to paper over the problem that
easily. Th
Hi Robert,
On 2013-10-03 14:39:46 -0400, Robert Haas wrote:
> On Mon, Sep 23, 2013 at 9:36 AM, Alvaro Herrera
> wrote:
> > I think the idea that we should consider a different way of handling
> > tabular configuration data has merit. In fact, how much sense does it
> > make to have these options
On Mon, Sep 23, 2013 at 9:36 AM, Alvaro Herrera
wrote:
> I think the idea that we should consider a different way of handling
> tabular configuration data has merit. In fact, how much sense does it
> make to have these options (the ones for which this patch is being
> written) be GUCs in the firs
On Mon, Sep 23, 2013 at 7:06 PM, Alvaro Herrera
wrote:
> I think the idea that we should consider a different way of handling
> tabular configuration data has merit. In fact, how much sense does it
> make to have these options (the ones for which this patch is being
> written) be GUCs in the firs
I think the idea that we should consider a different way of handling
tabular configuration data has merit. In fact, how much sense does it
make to have these options (the ones for which this patch is being
written) be GUCs in the first place? ALTER USER/DATABASE don't work for
them, they can't be
On Fri, Sep 20, 2013 at 9:48 AM, Amit Kapila wrote:
> On Thu, Sep 19, 2013 at 2:48 PM, Andres Freund wrote:
>> On 2013-09-18 11:02:50 +0200, Andres Freund wrote:
>>> On 2013-09-18 11:55:24 +0530, Amit Kapila wrote:
>>>
>>> > > I think that ship has long since sailed. postgresql.conf has allowed
>
On Thu, Sep 19, 2013 at 6:19 PM, Andres Freund wrote:
> On 2013-09-19 14:57:53 -0400, Robert Haas wrote:
>> On Tue, Sep 17, 2013 at 6:56 PM, Andres Freund
>> wrote:
>> > I think that ship has long since sailed. postgresql.conf has allowed
>> > foo.bar style GUCs via custom_variable_classes for a
On Thu, Sep 19, 2013 at 2:48 PM, Andres Freund wrote:
> On 2013-09-18 11:02:50 +0200, Andres Freund wrote:
>> On 2013-09-18 11:55:24 +0530, Amit Kapila wrote:
>>
>> > > I think that ship has long since sailed. postgresql.conf has allowed
>> > > foo.bar style GUCs via custom_variable_classes for a
On 2013-09-19 14:57:53 -0400, Robert Haas wrote:
> On Tue, Sep 17, 2013 at 6:56 PM, Andres Freund wrote:
> > I think that ship has long since sailed. postgresql.conf has allowed
> > foo.bar style GUCs via custom_variable_classes for a long time, and
> > these days we don't even require that but al
On Tue, Sep 17, 2013 at 6:56 PM, Andres Freund wrote:
>> That's more or less what I figured. One thing I'm uncomfortable with
>> is that, while this is useful for extensions, what do we do when we
>> have a similar requirement for core? The proposed GUC name is of the
>> format extension.user_de
On 2013-09-18 11:02:50 +0200, Andres Freund wrote:
> On 2013-09-18 11:55:24 +0530, Amit Kapila wrote:
>
> > > I think that ship has long since sailed. postgresql.conf has allowed
> > > foo.bar style GUCs via custom_variable_classes for a long time, and
> > > these days we don't even require that b
On 2013-09-18 11:55:24 +0530, Amit Kapila wrote:
> > I think that ship has long since sailed. postgresql.conf has allowed
> > foo.bar style GUCs via custom_variable_classes for a long time, and
> > these days we don't even require that but allow them generally. Also,
> > SET, postgres -c, and SELE
Hi,
On 2013-09-17 16:24:34 -0400, Robert Haas wrote:
> On Tue, Sep 17, 2013 at 10:27 AM, Andres Freund
> wrote:
> > On 2013-09-17 10:23:30 -0400, Robert Haas wrote:
> >> What is the use case for this change?
> >
> > Check
> > http://archives.postgresql.org/message-id/20130225213400.GF3849%40awo
On Tue, Sep 17, 2013 at 10:27 AM, Andres Freund wrote:
> On 2013-09-17 10:23:30 -0400, Robert Haas wrote:
>> On Sat, Sep 14, 2013 at 5:21 PM, Andres Freund
>> wrote:
>> >> a) allow repeatedly qualified names like a.b.c
>> >
>> > The attached patch does a)
>>
>> What is the use case for this chan
On 2013-09-17 10:23:30 -0400, Robert Haas wrote:
> On Sat, Sep 14, 2013 at 5:21 PM, Andres Freund wrote:
> >> a) allow repeatedly qualified names like a.b.c
> >
> > The attached patch does a)
>
> What is the use case for this change?
Check
http://archives.postgresql.org/message-id/2013022521340
On Sat, Sep 14, 2013 at 5:21 PM, Andres Freund wrote:
>> a) allow repeatedly qualified names like a.b.c
>
> The attached patch does a)
What is the use case for this change?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers ma
On 2013-02-25 22:15:33 +0100, Andres Freund wrote:
> Currently guc-file.c allows the following as guc names:
>
> ID{LETTER}{LETTER_OR_DIGIT}*
> QUALIFIED_ID {ID}"."{ID}
>
> That is either one token starting with a letter followed by numbers or
> letters or exactly two of those separa
Robert Haas writes:
> On Fri, Sep 6, 2013 at 6:31 PM, Andres Freund wrote:
>> On 2013-09-06 14:48:33 -0400, Tom Lane wrote:
>>> Well, sure, but I would think that ALTER SYSTEM SET should be constrained
>>> to only set known GUCs, not invent new ones on the fly.
>> Hm. That sounds inconvenient to
Andres Freund writes:
> On 2013-09-06 10:13:23 -0400, Tom Lane wrote:
>> Well, if you feel an absolute compulsion to make them consistent, I'd
>> go with making SET disallow creation of variables with names the file
>> parser wouldn't recognize. But why is it such a bad thing if SET can
>> do tha
On Fri, Sep 6, 2013 at 6:31 PM, Andres Freund wrote:
> On 2013-09-06 14:48:33 -0400, Tom Lane wrote:
>> Andres Freund writes:
>> > On 2013-09-06 10:13:23 -0400, Tom Lane wrote:
>> >> Well, if you feel an absolute compulsion to make them consistent, I'd
>> >> go with making SET disallow creation o
On 2013-09-06 14:48:33 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-09-06 10:13:23 -0400, Tom Lane wrote:
> >> Well, if you feel an absolute compulsion to make them consistent, I'd
> >> go with making SET disallow creation of variables with names the file
> >> parser wouldn't recogni
Hannu Krosing writes:
> On 09/06/2013 08:48 PM, Tom Lane wrote:
>> Well, sure, but I would think that ALTER SYSTEM SET should be constrained
>> to only set known GUCs, not invent new ones on the fly.
> What's the reasoning behind this ?
If you don't know what a GUC is, you don't know what are va
On 09/06/2013 08:48 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2013-09-06 10:13:23 -0400, Tom Lane wrote:
>>> Well, if you feel an absolute compulsion to make them consistent, I'd
>>> go with making SET disallow creation of variables with names the file
>>> parser wouldn't recognize. But w
Andres Freund writes:
> On 2013-02-25 21:13:25 -0500, Tom Lane wrote:
>>> b) allow variables to start with a digit from the second level onwards.
>> That seems like a seriously bad idea. I note that SET does *not* allow
>> this;
> Hm. One thing about this is that we currently allow something si
On 2013-09-06 10:13:23 -0400, Tom Lane wrote:
> Andres Freund writes:
> >> That seems like a seriously bad idea. I note that SET does *not* allow
> >> this;
>
> > Hm. One thing about this is that we currently allow something silly as:
> > SET "1"."1bar""blub" = 3;
>
> > So I'd like to either rest
On 2013-02-25 21:13:25 -0500, Tom Lane wrote:
> > b) allow variables to start with a digit from the second level onwards.
>
> That seems like a seriously bad idea. I note that SET does *not* allow
> this;
Hm. One thing about this is that we currently allow something silly as:
SET "1"."1bar""blub
On 2013-02-26 13:08:54 +0100, Andres Freund wrote:
> Just for reference, thats the grammar for SET/SHOW:
>
> var_name: ColId
> { $$ = $1; }
> | var_name '.' ColId
>
> Any arguments whether we should try to validate
On 2013-02-25 21:13:25 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I propose loosening those restrictions to
> > a) allow repeatedly qualified names like a.b.c
>
> If SET allows it, I guess we can allow it here. But is a grammar change
> really all that is needed to make it work from the
Andres Freund writes:
> I propose loosening those restrictions to
> a) allow repeatedly qualified names like a.b.c
If SET allows it, I guess we can allow it here. But is a grammar change
really all that is needed to make it work from the file?
> b) allow variables to start with a digit from the
On 02/25/2013 04:34 PM, Andres Freund wrote:
Not that as I said before
SET foo.bar.blub = '1'; currently is already allowed.
I gather you mean "Note". I agree that it seems very odd to allow this
in one context and forbid it in another.
cheers
andrew
--
Sent via pgsql-hackers mailing l
On 2013-02-25 22:27:21 +0100, Pavel Stehule wrote:
> Why?
The concrete usecase is having some form of nesting available for a
shared_library.
shared_preload_libraries = 'bdr'
bdr.connections = 'a, b'
bdr.a.dsn = '...'
bdr.a.xxx = '...'
bdr.b.dsn = '...'
> There are no multilevels structures in
Hello
Why? There are no multilevels structures in pg. Variables should be joined
with schemas or extensions. Other levels are messy.
35 matches
Mail list logo
