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
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
(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
* 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/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
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
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 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
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
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
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
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.
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
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
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
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
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
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
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
19 matches
Mail list logo
