From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> |
Cc: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Extensions, this time with a patch |
Date: | 2010-11-22 21:59:52 |
Message-ID: | 1290462918-sup-683@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Dimitri Fontaine's message of lun nov 22 18:12:39 -0300 2010:
> Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> writes:
> > No. My suggestion was just to use the internal parser.
>
> What about something like the attached, cfparser.v3.patch?
>
> If that looks ok, do we want to add some documentation about the new
> lexer capabilities? Also, for what good reason would we want to prevent
> people from using the include facility?
Hmm, the first thought that comes to mind is that the GucContext param
to ParseConfigFile is unused and can be removed. This is probably an
oversight from when include files were introduced in 2006.
I don't like the fact that this code handles custom_variable_classes
internally. I think this would be exposed to the parsing of extension
control files, which is obviously wrong.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2010-11-22 22:02:31 | Re: Extensions, this time with a patch |
Previous Message | Robert Haas | 2010-11-22 21:59:30 | Re: final patch - plpgsql: for-in-array |