Andrew Dunstan wrote:
> The attached patch adds a test for libxslt/xslt.h and only builds
> contrib/xml2 if it's found,
But the policy is that the presence of features in the final build
should not depend on the incidental presence of features in the build
environment. Either you select a featu
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The attached patch adds a test for libxslt/xslt.h and only builds
contrib/xml2 if it's found, which I think should handle Peter's
objection, as well as unbreak the buildfarm. (The patch is large because
cvs diff seems to have beha
Peter Eisentraut wrote:
Andrew Dunstan wrote:
The attached patch adds a test for libxslt/xslt.h and only builds
contrib/xml2 if it's found,
But the policy is that the presence of features in the final build
should not depend on the incidental presence of features in the build
envir
Bruce Momjian wrote:
Andrew Dunstan wrote:
Peter Eisentraut wrote:
And if it is, then you have several options:
. don't configure with libxml, or
. don't build contrib modules from the contrib Makefile (use the
individual module Makefiles instead), or
. change the xml2 Makefile
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> But the policy is that the presence of features in the final build
>> should not depend on the incidental presence of features in the build
>> environment. Either you select a feature, then it's built, or you
>> don't, then
Hello
I searched some notes about this topic. I didn't find any usefull sample.
Lot of samples are about external stored procedures and others about using
table expression like
create function foo(i1)
returns table (a1 int)
as
return table(select a1 from tab)
isn't clear if table attributes
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Peter Eisentraut wrote:
>>> But the policy is that the presence of features in the final build
>>> should not depend on the incidental presence of features in the build
>>> environment. Either you select a feature, then it's built,
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Peter Eisentraut wrote:
But the policy is that the presence of features in the final build
should not depend on the incidental presence of features in the build
environment. Either you select a feature, then it's built, or y
I wrote:
> Thinking more about this leads me to the following proposal:
> 1. Explicitly group the indexes according to the subset of
> WHERE-conditions (and partial index conditions, if any) they use.
> Within each such group, discard all but the cheapest-scan-cost one.
> 2. Sort the remaining in
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
So, I should allow DROP DEFAULT, implement
SET DEFAULT GENERATED ALWAYS AS
and modify the catalog so the GENERATED property
is part of pg_attrdef.
Sounds good.
Finally here it is.
What about IDENTITY?
Should it also b
Zoltan Boszormenyi írta:
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
So, I should allow DROP DEFAULT, implement
SET DEFAULT GENERATED ALWAYS AS
and modify the catalog so the GENERATED property
is part of pg_attrdef.
Sounds good.
Finally here it is.
What about I
Steve, can you try this out on your queries and see if it makes better
or worse decisions? It seems to fix your initial complaint but I do
not have a large stock of test cases to try.
Wow, this is a remarkable difference. Queries that were taking
minutes to complete are coming up in seconds
Steve <[EMAIL PROTECTED]> writes:
>> Steve, can you try this out on your queries and see if it makes better
>> or worse decisions? It seems to fix your initial complaint but I do
>> not have a large stock of test cases to try.
> Wow, this is a remarkable difference. Queries that were takin
13 matches
Mail list logo
