Bruce Momjian wrote:
I have updated the documentation for this patch. I consider it ready to
apply. I think it is as close to a middle ground as we are going to
get. Further adjustment will have to happen when we have more reports
from the field.
I heard a pretty compelling argument to make "
I have updated the documentation for this patch. I consider it ready to
apply. I think it is as close to a middle ground as we are going to
get. Further adjustment will have to happen when we have more reports
from the field.
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Hmm, I'm now wondering if the location should be added to Value as well,
> so that it can be passed down to Const?
Just for the record, we don't want it in Const. Parse locations are
only useful in the "raw grammar" output, mainly because they aren't
h
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I came up with the attached patch.
>
> I wasn't envisioning anything anywhere near this invasive. We only
> need locations on constants in a few contexts, I think.
Aha. OK, I'll commit the original patch and let you deal with t
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I came up with the attached patch.
I wasn't envisioning anything anywhere near this invasive. We only
need locations on constants in a few contexts, I think.
BTW, you broke _equalAConst() ... it was a bad idea anyway to recast
it on the assumption tha
Alvaro Herrera escribió:
> Tom Lane escribió:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > Tom Lane escribió:
> > >> They're logically different things, and after I get done putting a parse
> > >> location field into A_Const, they'll still be physically different too.
> >
> > > Aha. Are y
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane escribió:
> >> They're logically different things, and after I get done putting a parse
> >> location field into A_Const, they'll still be physically different too.
>
> > Aha. Are you working from Brendan's patch? I was
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> They're logically different things, and after I get done putting a parse
>> location field into A_Const, they'll still be physically different too.
> Aha. Are you working from Brendan's patch? I was going to commit it.
Sure, go
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Brendan Jurd escribi�:
> >> Here's my attempt to remove the typename field from A_Const. There
> >> were a few places (notably flatten_set_variable_args() in guc.c, and
> >> typenameTypeMod() in parse_type.c) where the code expect
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Brendan Jurd escribió:
>> Here's my attempt to remove the typename field from A_Const. There
>> were a few places (notably flatten_set_variable_args() in guc.c, and
>> typenameTypeMod() in parse_type.c) where the code expected to see an
>> A_Const with
Brendan Jurd escribió:
> Here's my attempt to remove the typename field from A_Const. There
> were a few places (notably flatten_set_variable_args() in guc.c, and
> typenameTypeMod() in parse_type.c) where the code expected to see an
> A_Const with a typename, and I had to adjust for an A_Const w
Pavel Stehule escribió:
> This patch contains generate_subscripts functions, that generate
> series of array's subscripts of some dimension:
Committed, thanks.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent
Hi.
Thanks!
- Original Message -
From: "Magnus Hagander" <[EMAIL PROTECTED]>
Hiroshi Saito wrote:
Hi.
Eh? It is strange...
http://winpg.jp/~saito/pg_work/WIN32_BUILD_INF/psql_win32.mak
Actually, it is required although psql is built. Have I missed
something?
Note that building p
Hiroshi Saito wrote:
> Hi.
>
> Eh? It is strange...
> http://winpg.jp/~saito/pg_work/WIN32_BUILD_INF/psql_win32.mak
> Actually, it is required although psql is built. Have I missed
> something?
Note that building psql this way really isn't supported anymore :-)
Anyway. If you get references to i
14 matches
Mail list logo
