Hi,
sorry for the delay...
btw, the patch no longer apply cleanly but most are just hunks the
worst it's in src/backend/catalog/namespace.c because
FindConversionByName() is now called get_conversion_oid()... so maybe
this function should be named get_collation_oid(), i guess
On Tue, Aug 3, 2010
On Sat, Aug 14, 2010 at 08:40:24AM +0200, Boszormenyi Zoltan wrote:
> Andres Freund írta:
> > On Fri, Aug 13, 2010 at 09:36:00PM +0200, Boszormenyi Zoltan wrote:
> >
> >> Tom Lane írta:
> >>
> >>> Boszormenyi Zoltan writes:
> >>>
> >>>
> attached is a WIP patch that will eventually implement
On 2010-08-08 1:45 PM +0300, I wrote:
On 8/8/2010 12:49 PM, Dean Rasheed wrote:
For those migrating code from Oracle, providing this feature as-is
might be valuable, since presumably they are not too concerned about
these concurrency issues. Ideally we'd want to do better though.
Yes, you migh
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I'm not sure whether there is any clear rule for what rows you get when
> >> grouping by a non-PK column in mysql, but it'll let you do it.
>
> > I understand this. The issue is how many people who complained about
> > our GROUP BY
Andres Freund writes:
> On Sat, Aug 14, 2010 at 08:40:24AM +0200, Boszormenyi Zoltan wrote:
>> And in this patch, the startup process only tries to connect
>> after signalling the postmaster that a consistent state is reached.
>> And the connection has a reasonable timeout built in.
> I don't thi
Bruce Momjian writes:
> Tom Lane wrote:
>> No doubt, but the TODO entry you removed is still 100% accurately
>> worded, and what's more the archive entry it links to clearly describes
>> exactly the point at issue, namely that grouping by a PK *isn't*
>> indeterminate. You were wrong to remove it
Hitoshi Harada writes:
> 2010/8/14 Itagaki Takahiro :
>> 2010/8/10 Tom Lane :
>>> Eventually it might be nice to have some sort of way to specify the
>>> estimate to use for any aggregate function --- but for a near-term
>>> fix maybe we should just hard-wire a special case for array_agg in
>>> co
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> No doubt, but the TODO entry you removed is still 100% accurately
> >> worded, and what's more the archive entry it links to clearly describes
> >> exactly the point at issue, namely that grouping by a PK *isn't*
> >> indeterminate.
Pavel Stehule writes:
> attached updated \sf implementation. It is little bit simplyfied with
> support a pager and output forwarding. Formating was updated per Tom's
> request.
Applied with corrections --- mostly, fixing it to not trash the query
buffer, which would certainly not be expected beh
Hitoshi Harada writes:
> 2010/8/14 Itagaki Takahiro :
>> The attached patch is the near-term fix; it adds ALLOCSET_DEFAULT_INITSIZE
>> bytes to memory assumption.
>>
>> We might need the same adjustment for string_agg(), that consumes
>> 1024 bytes for the transit condition. array_agg() and strin
James William Pye writes:
> On Aug 13, 2010, at 5:20 PM, Tom Lane wrote:
>> I see several calls in plpython.c that seem to refer to PyCObject stuff.
>> Anybody have any idea if we need to do something about this?
> Well, we should at least be checking for an exception here anyways:
> pro
On Aug 14, 2010, at 9:08 AM, Tom Lane wrote:
> Just to clarify, you're recommending something like
>
> proc->me = PyCObject_FromVoidPtr(proc, NULL);
> + if (proc->me == NULL)
> + elog(ERROR, "could not create PyCObject for function");
> P
Tom Lane wrote:
> Jaime Casanova writes:
> > A few months ago Bruce was doing a hunting of personal Copyrights
> > notices, but i still found a lot of files copyrighted to: Regents of
> > the University of California and other files copyrighted to
> > individuals (ej: almost everything inside src/
On 14 August 2010 13:12, Marko Tiikkaja wrote:
> On 2010-08-08 1:45 PM +0300, I wrote:
>>
>> On 8/8/2010 12:49 PM, Dean Rasheed wrote:
>>>
>>> For those migrating code from Oracle, providing this feature as-is
>>> might be valuable, since presumably they are not too concerned about
>>> these concu
(2010/08/10 8:39), Robert Haas wrote:
2010/8/9:
2. Some of this code refers to "local" security labels. I'm not sure
what's "local" about them - aren't they just security labels? On a
related note, I don't like the trivial wrappers you have here, with
DeleteSecurityLabel around DeleteLocalSecL
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
> Yep, rte->requiredPerms of inherited relations are cleared on the
> expand_inherited_rtentry() since the v9.0, so we cannot know what
> kind of accesses are required on the individual child relations.
This is really a PG issue and decision, in my view.
(2010/08/15 9:16), Stephen Frost wrote:
> * KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
>> Yep, rte->requiredPerms of inherited relations are cleared on the
>> expand_inherited_rtentry() since the v9.0, so we cannot know what
>> kind of accesses are required on the individual child relations.
>
> Th
2010/8/14 KaiGai Kohei :
> (2010/08/15 9:16), Stephen Frost wrote:
>> * KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
>>> Yep, rte->requiredPerms of inherited relations are cleared on the
>>> expand_inherited_rtentry() since the v9.0, so we cannot know what
>>> kind of accesses are required on the indi
Excerpts from Peter Eisentraut's message of mié ago 11 11:23:19 -0400 2010:
> On fre, 2010-08-06 at 08:12 +0100, Simon Riggs wrote:
> > Given that Peter is now attending SQL Standards meetings, I would
> > suggest we leave out my suggestion above, for now. We have time to
> > raise this at standard
19 matches
Mail list logo
