Andres Freund írta:
On Fri, Aug 13, 2010 at 09:36:00PM +0200, Boszormenyi Zoltan wrote:
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
attached is a WIP patch that will eventually implement
partial replication, with the following syntax:
This
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 z...@cybertec.at writes:
attached is a WIP patch that will eventually implement
partial
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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Andres Freund and...@anarazel.de 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.
Bruce Momjian br...@momjian.us 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
Hitoshi Harada umi.tan...@gmail.com writes:
2010/8/14 Itagaki Takahiro itagaki.takah...@gmail.com:
2010/8/10 Tom Lane t...@sss.pgh.pa.us:
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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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*
Pavel Stehule pavel.steh...@gmail.com 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
Hitoshi Harada umi.tan...@gmail.com writes:
2010/8/14 Itagaki Takahiro itagaki.takah...@gmail.com:
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
James William Pye li...@jwp.name 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:
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);
Tom Lane wrote:
Jaime Casanova ja...@2ndquadrant.com 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
On 14 August 2010 13:12, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
(2010/08/10 8:39), Robert Haas wrote:
2010/8/9kai...@kaigai.gr.jp:
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
* 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.
This is
2010/8/14 KaiGai Kohei kai...@kaigai.gr.jp:
(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
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 standards
20 matches
Mail list logo
