On Tue, Oct 12, 2010 at 2:25 PM, Alvaro Herrera
wrote:
> Excerpts from Richard Evans's message of mar oct 12 12:48:45 -0300 2010:
>
>> When cross compiling for Windows using a separate build area, libpq.dll does
>> not build because the .def file cannot be found.
>>
>> This appears to be caused by
So, did ssl_ciphers go away on purpose? If so, why? If not, why isn't it
accessible?
Are you sure you're on an SSL enabled build?
Oh, good call ... I thought I'd installed the SSL build, but apparently not.
Mind you, we *also* need a doc patch. ("This parameter is only available
if Postg
On Fri, Oct 29, 2010 at 10:01, Josh Berkus wrote:
>
>>> So, did ssl_ciphers go away on purpose? If so, why? If not, why isn't
>>> it
>>> accessible?
>>
>> Are you sure you're on an SSL enabled build?
>
> Oh, good call ... I thought I'd installed the SSL build, but apparently not.
>
> Mind you, w
Magnus Hagander writes:
> On Fri, Oct 29, 2010 at 10:01, Josh Berkus wrote:
>> Mind you, we *also* need a doc patch. ("This parameter is only available if
>> PostgreSQL was built with SSL support").
> Actually, I think it'd be more user friendly to make the parameter
> still exist and be a no-op
[ please continue any further discussion in pgsql-bugs only ]
"Kevin Grittner" writes:
> Tom Lane wrote:
>> BTW this seems pretty far off-topic for pgsql-performance.
> It is once you understand what's happening. It was probably the 11+
> minutes for the mistyped query run, versus the 28 ms w
On Fri, Oct 29, 2010 at 3:07 PM, Tom Lane wrote:
> [ please continue any further discussion in pgsql-bugs only ]
>
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> BTW this seems pretty far off-topic for pgsql-performance.
>
>> It is once you understand what's happening. It was probably the 11
Robert Haas wrote:
>> 2. The notation t(x) will be taken to mean x::t if there's no
>> function t() taking x's type, but there is a cast from x's type
>> to t.
>> I think if I had to pick a proposal, I'd say we should disable #2
>> for the specific case of casting a composite type to something
On Fri, Oct 29, 2010 at 1:56 PM, Tom Lane wrote:
> But for user-facing parameters I agree we should do it,
> and ssl_ciphers is one of those.
+1.
> In any case, a doc patch would be the right thing for the back branches.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpr
"Kevin Grittner" writes:
> Robert Haas wrote:
>>> I think if I had to pick a proposal, I'd say we should disable #2
>>> for the specific case of casting a composite type to something
>>> else.
>> Well, then let's do that. It's not the exact fix I'd pick, but
>> it's clearly better than nothing
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Robert Haas wrote:
I think if I had to pick a proposal, I'd say we should disable
#2 for the specific case of casting a composite type to
something else.
>
>>> Well, then let's do that. It's not the exact fix I'd pick, but
>>> it's
Excerpts from Robert Haas's message of vie oct 29 13:23:39 -0300 2010:
> On Tue, Oct 12, 2010 at 2:25 PM, Alvaro Herrera
> wrote:
> > Excerpts from Richard Evans's message of mar oct 12 12:48:45 -0300 2010:
> >
> >> When cross compiling for Windows using a separate build area, libpq.dll
> >> does
On Oct 29, 2010, at 4:21 PM, "Kevin Grittner"
wrote:
> Tom Lane wrote:
>> "Kevin Grittner" writes:
>>> Robert Haas wrote:
> I think if I had to pick a proposal, I'd say we should disable
> #2 for the specific case of casting a composite type to
> something else.
>>
Well, then
Robert Haas writes:
> Yeah, I think we're going to have to live with it, at least for 8.4. One
> could make an argument that 9.0 is new enough we could get away with a small
> behavior change to avoid a large amount of user confusion. But that may be a
> self-serving argument based on wanting
On Oct 29, 2010, at 5:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yeah, I think we're going to have to live with it, at least for 8.4. One
>> could make an argument that 9.0 is new enough we could get away with a small
>> behavior change to avoid a large amount of user confusion. But that
14 matches
Mail list logo
