On Wed, Mar 28, 2012 at 8:52 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 28, 2012 at 11:28 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
In practice, however, that sounds like a real pain in the neck. I
would expect most people who were packaging extensions to handle a
On Mon, Mar 26, 2012 at 12:14 AM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote:
On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina dan...@heroku.com wrote:
Parallel to
Hitoshi Harada umi.tan...@gmail.com writes:
Frankly I'm still against this patch. Since I started to review it
I've never been convinced with the use case. Yeah, someone said it'd
be useful to him, but as a developer of some of PGXN modules I don't
see it. I totally agree with Robert's
On Thu, Mar 29, 2012 at 12:51 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Hitoshi Harada umi.tan...@gmail.com writes:
Frankly I'm still against this patch. Since I started to review it
I've never been convinced with the use case. Yeah, someone said it'd
be useful to him, but as a
On Wed, Mar 28, 2012 at 10:54:58PM +0100, Simon Riggs wrote:
On Wed, Mar 28, 2012 at 10:24 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Mar 28, 2012 at 9:48 PM, Marko Kreen mark...@gmail.com wrote:
On Fri, Mar 23, 2012 at 08:52:40AM +, Simon Riggs wrote:
Master pg_controldata -
Hitoshi Harada umi.tan...@gmail.com writes:
So my question is why you cannot depend on ip4r in that case. If some
version of the module introduces ipv6, then let's depend on that
version. It doesn't explain why a string feature name is needed.
The only operator we have to compare version
Hi,
Thanks for your review!
Robert Haas robertmh...@gmail.com writes:
I think the lack of pg_upgrade support is a must-fix before commit.
I though that would only be a TODO for 9.2 to 9.3 upgrades. When
upgrading from 9.1 to 9.2, pg_upgrade will directly stuff extensions
using
On Wed, Mar 28, 2012 at 10:54 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Mar 28, 2012 at 10:24 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Mar 28, 2012 at 9:48 PM, Marko Kreen mark...@gmail.com wrote:
On Fri, Mar 23, 2012 at 08:52:40AM +, Simon Riggs wrote:
Master
On Thu, Mar 29, 2012 at 10:37:54AM +0100, Simon Riggs wrote:
When the standby receives the checkpoint record, it stores the
information in 2 places:
i) directly into ControlFile-checkPointCopy
ii) and then into XLogCtl when a safe restartpoint occurs
In RecoveryRestartPoint() I see:
-
On Wed, Mar 28, 2012 at 9:54 PM, Joachim Wieland j...@mcknight.de wrote:
On Wed, Mar 28, 2012 at 1:46 PM, Robert Haas robertmh...@gmail.com wrote:
I'm wondering if we really need this much complexity around shutting
down workers. I'm not sure I understand why we need both a hard and
a soft
On Wed, Mar 28, 2012 at 10:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The SELECT INTO tests all fail, but we know the reason why (the testbed
isn't expecting them to result in creating separate entries for the
utility statement and the underlying plannable SELECT).
This might be a dumb idea,
On Wed, Mar 28, 2012 at 3:41 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
What about :
create command trigger foo before prepare alter table …
create command trigger foo before start of alter table …
create command trigger foo before execute alter table …
create command trigger foo
On Thu, Mar 29, 2012 at 11:12 AM, Marko Kreen mark...@gmail.com wrote:
On Thu, Mar 29, 2012 at 10:37:54AM +0100, Simon Riggs wrote:
When the standby receives the checkpoint record, it stores the
information in 2 places:
i) directly into ControlFile-checkPointCopy
ii) and then into XLogCtl
On 29 March 2012 02:09, Tom Lane t...@sss.pgh.pa.us wrote:
Thanks. I've committed the patch along with the docs, after rather
heavy editorialization.
Thank you.
1. What to do with EXPLAIN, SELECT INTO, etc. We had talked about
tweaking the behavior of statement nesting and some other
On Thu, Mar 29, 2012 at 4:37 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Hitoshi Harada umi.tan...@gmail.com writes:
So my question is why you cannot depend on ip4r in that case. If some
version of the module introduces ipv6, then let's depend on that
version. It doesn't explain why a
Robert Haas wrote:
I think that technically this patch can be polished well enough to
commit in the time we have available, but the question of whether
it's the right design is harder, and I don't want that to be my
call alone.
I gather from previous posts that the intent isn't to allow
2012-03-29 12:59 keltezéssel, Boszormenyi Zoltan írta:
2012-03-29 02:43 keltezéssel, Noah Misch írta:
On Sat, Mar 24, 2012 at 10:49:07AM +0100, Boszormenyi Zoltan wrote:
+the window size may be modified by setting
theliteralECPGFETCHSZ/literal
+environment variable to a different
Robert Haas robertmh...@gmail.com writes:
I am sure that we could find a way to beat this with a stick until it
behaves, but I don't really like that idea. It seems to me to be a
[...]
we should learn from that lesson: when you may want to have a bunch of
I first wanted to ensure that reusing
On Thu, Mar 29, 2012 at 1:01 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
I gather from previous posts that the intent isn't to allow different
packages from different authors to provide a common and compatible
feature; but what happens in the current design if someone
accidentally or
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I gather from previous posts that the intent isn't to allow different
packages from different authors to provide a common and compatible
feature; but what happens in the current design if someone
accidentally or maliciously produces an
On Thu, Mar 29, 2012 at 8:01 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas wrote:
I think that technically this patch can be polished well enough to
commit in the time we have available, but the question of whether
it's the right design is harder, and I don't want that to
On 29 March 2012 13:30, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
I'll go make that happen, and still need input here. We first want to
have command triggers on specific commands or ANY command, and we want
to implement 3 places from where to fire them.
Here's a new syntax proposal to
On Thu, Mar 29, 2012 at 12:06 PM, Simon Riggs si...@2ndquadrant.com wrote:
Patch coming in a few hours.
This is more straightforward than I was thinking. We just need to
initialise XLogCtl at the right place.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL
On Thu, Mar 29, 2012 at 9:01 AM, Thom Brown t...@linux.com wrote:
On 29 March 2012 13:30, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
I'll go make that happen, and still need input here. We first want to
have command triggers on specific commands or ANY command, and we want
to implement 3
On Thu, Mar 29, 2012 at 02:46:23PM +0100, Simon Riggs wrote:
On Thu, Mar 29, 2012 at 12:06 PM, Simon Riggs si...@2ndquadrant.com wrote:
Patch coming in a few hours.
This is more straightforward than I was thinking. We just need to
initialise XLogCtl at the right place.
Looks good to me.
On Thu, Mar 29, 2012 at 3:04 PM, Marko Kreen mark...@gmail.com wrote:
On Thu, Mar 29, 2012 at 02:46:23PM +0100, Simon Riggs wrote:
On Thu, Mar 29, 2012 at 12:06 PM, Simon Riggs si...@2ndquadrant.com wrote:
Patch coming in a few hours.
This is more straightforward than I was thinking. We just
On Thu, Mar 29, 2012 at 03:23:01PM +0100, Simon Riggs wrote:
On Thu, Mar 29, 2012 at 3:04 PM, Marko Kreen mark...@gmail.com wrote:
Next question: how can flipping archive_mode on and off,
with restarts, near wraparound point, break epoch on master?
Hi guys,
Something from Josh's recent blog post about summer of code clicked with me
- the HTTP / SQL concept.
It was something I'd been thinking about earlier, how people really like
HTTP APIs and this is one of the drivers behind adoption of some NoSQL
databases out there.
Some things that I
On 03/29/2012 10:37 AM, Dobes Vandermeer wrote:
Hi guys,
Something from Josh's recent blog post about summer of code clicked
with me - the HTTP / SQL concept.
It was something I'd been thinking about earlier, how people really
like HTTP APIs and this is one of the drivers behind adoption
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 28, 2012 at 10:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The SELECT INTO tests all fail, but we know the reason why (the testbed
isn't expecting them to result in creating separate entries for the
utility statement and the underlying
On Thu, Mar 29, 2012 at 8:30 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
I'll go make that happen, and still need input here. We first want to
have command triggers on specific commands or ANY command, and we want
to implement 3 places from where to fire them.
Here's a new syntax
Robert Haas robertmh...@gmail.com writes:
On Thu, Mar 29, 2012 at 9:01 AM, Thom Brown t...@linux.com wrote:
On 29 March 2012 13:30, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
I'll go make that happen, and still need input here. We first want to
have command triggers on specific commands or
On Thu, Mar 29, 2012 at 11:23 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It would make more sense to me to go the other way, that is suppress
creation of a separate entry for the contained optimizable statement.
The stats will still be correctly accumulated into the surrounding
statement (or at
Robert Haas robertmh...@gmail.com writes:
On Thu, Mar 29, 2012 at 11:23 AM, Tom Lane t...@sss.pgh.pa.us wrote:
However, I think there is a solution for that, though it may sound a bit
ugly. Rather than just stacking a flag, let's stack the query source
text pointer for the utility statement.
On 29 March 2012 16:30, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Mar 29, 2012 at 9:01 AM, Thom Brown t...@linux.com wrote:
On 29 March 2012 13:30, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
I'll go make that happen, and still need
On 28.03.2012 23:54, Pavel Stehule wrote:
2012/3/28 Heikki Linnakangasheikki.linnakan...@enterprisedb.com:
In prepare_expr(), you use a subtransaction to catch any ERRORs that happen
during parsing the expression. That's a good idea, and I think many of the
check_* functions could be greatly
On Thu, Mar 29, 2012 at 11:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Mar 29, 2012 at 11:23 AM, Tom Lane t...@sss.pgh.pa.us wrote:
However, I think there is a solution for that, though it may sound a bit
ugly. Rather than just stacking a flag,
Robert Haas robertmh...@gmail.com writes:
What I'm imagining is that instead of just having a global for
nested_level, you'd have a global variable pointing to a linked list.
This is more or less what I have in mind, too, except I do not believe
that a mere boolean flag is sufficient to tell
Robert Haas robertmh...@gmail.com writes:
create command trigger before COMMAND_STEP of alter table
execute procedure snitch();
One thought is that it might be better to say AT or ON or WHEN rather
than BEFORE, since BEFORE END is just a little strange; and also
because a future
On Thu, Mar 29, 2012 at 11:49 AM, Thom Brown t...@linux.com wrote:
On 29 March 2012 16:30, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Mar 29, 2012 at 9:01 AM, Thom Brown t...@linux.com wrote:
On 29 March 2012 13:30, Dimitri Fontaine
[ forgot to respond to this bit ]
Robert Haas robertmh...@gmail.com writes:
Another thought is: if we simply treated these as nested queries for
all purposes, would that really be so bad?
That was actually what I suggested first, and now that I look at the
code, that's exactly what's happening
Robert Haas robertmh...@gmail.com writes:
I've said repeatedly and over a long period of time that development
of this feature wasn't started early enough in the cycle to get it
finished in time for 9.2. I think that I've identified some pretty
That could well be, yeah.
serious issues in
2012/3/29 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
On 28.03.2012 23:54, Pavel Stehule wrote:
2012/3/28 Heikki Linnakangasheikki.linnakan...@enterprisedb.com:
In prepare_expr(), you use a subtransaction to catch any ERRORs that
happen
during parsing the expression. That's a
On ons, 2012-03-28 at 22:12 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I propose that we apply the attached patch to make sure those variables
are set to a usable default value in any case.
Won't this break usages such as in contrib/cube?
cubeparse.c: cubeparse.y
Peter Eisentraut pete...@gmx.net writes:
On ons, 2012-03-28 at 22:12 -0400, Tom Lane wrote:
Won't this break usages such as in contrib/cube?
No, the code in my patch is conditional on 'ifdef PGXS'. (Not visible
in the patch, unfortunately.)
Oh, okay.
I don't think we want to support
On Thu, Mar 29, 2012 at 12:17 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
create command trigger before COMMAND_STEP of alter table
execute procedure snitch();
One thought is that it might be better to say AT or ON or WHEN rather
On Thu, Mar 29, 2012 at 12:59:40PM +0200, Boszormenyi Zoltan wrote:
2012-03-29 02:43 keltez?ssel, Noah Misch ?rta:
On Sat, Mar 24, 2012 at 10:49:07AM +0100, Boszormenyi Zoltan wrote:
+toliteralREADAHEAD number/literal. ExplicitliteralREADAHEAD
number/literal or
+literalNO
On Thu, Feb 23, 2012 at 8:35 PM, Daniele Varrazzo
daniele.varra...@gmail.com wrote:
On Mon, Feb 20, 2012 at 12:09 AM, Jan Urbański wulc...@wulczer.org wrote:
BTW, that tool is quite handy, I'll have to try running it over psycopg2.
Indeed. I'm having a play with it. It is reporting several
Apropos of nothing and since I haven't found a particularly good time
to say this in amidst all the technical discussion, I appreciate very
much all the work you've been putting into this.
On Thu, Mar 29, 2012 at 12:42 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
serious issues in the
On Mar 29, 2012, at 4:42 AM, Robert Haas wrote:
2. Add a new feature to the provides line with every release that does
anything other than fix bugs, leading to:
provides = foobar-1.1, foobar-1.2, foobar-1.3, foobar-1.4, foobar-1.5,
foobar-1.6, foobar-2.0, foobar-2.1, foobar-2.2, foobar-2.3,
I wrote:
Hm ... I just had a different idea. I need to go look at the code
again, but I believe that in the problematic cases, the post-analyze
hook does not compute a queryId for the optimizable statement. This
means that it will arrive at the executor with queryId zero. What if
we simply
On Thu, Mar 29, 2012 at 1:48 PM, David E. Wheeler da...@justatheory.com wrote:
On Mar 29, 2012, at 4:42 AM, Robert Haas wrote:
2. Add a new feature to the provides line with every release that does
anything other than fix bugs, leading to:
provides = foobar-1.1, foobar-1.2, foobar-1.3,
Robert Haas robertmh...@gmail.com writes:
provides = foobar-1.1, foobar-1.2, foobar-1.3, foobar-1.4, foobar-1.5,
foobar-1.6, foobar-2.0, foobar-2.1, foobar-2.2, foobar-2.3,
foobar-3.0, foobar-3.1
This is what I have expected to do. In new releases of pgTAP, I’d probably
just add version
Robert Haas robertmh...@gmail.com writes:
So the idea is that you're actually supposed to separately catalog
each feature you added (e.g. each new function), so that people can
depend specifically on those features.
I don't really have the foggiest idea how people using other packaging
On ons, 2012-03-28 at 23:00 -0700, Hitoshi Harada wrote:
I totally agree with Robert's point that one feature is not
standardized and nobody can tell how you can depend on the feature in
the end. Mind you, I've never heard about building dependency by its
name as a string in other packaging
On tor, 2012-03-29 at 09:51 +0200, Dimitri Fontaine wrote:
I don't want to introduce version dependency, because I don't think we
need it. If you want to compare what we're doing here with say debian
packaging, then look at how they package libraries. The major version
number is now part of
On Thu, Mar 29, 2012 at 01:03:41PM -0400, Noah Misch wrote:
Still, we're looking at dedicated ECPG syntax, quite visible even to folks
with no interest in Informix. We have eschewed littering our syntax with
compatibility aids, and I like it that way. IMO, an option to the ecpg
preprocessor
On Thu, Mar 29, 2012 at 2:28 PM, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2012-03-28 at 23:00 -0700, Hitoshi Harada wrote:
I totally agree with Robert's point that one feature is not
standardized and nobody can tell how you can depend on the feature in
the end. Mind you, I've never
Peter Eisentraut pete...@gmx.net writes:
At the very least, I would suggest that feature names are per-extension.
Yeah, I had about come to that conclusion too. A global namespace for
them would be a mistake given lack of central coordination.
regards, tom lane
--
On Thu, Mar 29, 2012 at 2:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. AFAIK, nobody actually does that. In my experience with Red Hat
packages, so-called virtual Provides (which are exactly equivalent to
this proposed feature) are used only for cases where there is or is
planned to be
On tor, 2012-03-29 at 14:39 -0400, Robert Haas wrote:
but it breaks down when you, say, want to
wrap your egg into a Debian package.
*blink* Huh?
Well, you can't represent that mechanism in a Debian (or RPM) package
dependency. So the alternatives are make it a Recommends and add a
On Mar 29, 2012, at 11:48 AM, Robert Haas wrote:
Frankly, I'm not sure we bet on the right horse in not mandating a
version numbering scheme from the beginning. But given that we
didn't, we probably don't want to get too forceful about it too
quickly. However, we could ease into it by
Tom Lane t...@sss.pgh.pa.us writes:
Peter Eisentraut pete...@gmx.net writes:
At the very least, I would suggest that feature names are per-extension.
Yeah, I had about come to that conclusion too. A global namespace for
them would be a mistake given lack of central coordination.
That's how
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Peter Eisentraut pete...@gmx.net writes:
At the very least, I would suggest that feature names are per-extension.
Yeah, I had about come to that conclusion too. A global namespace for
them would be a mistake
2012-03-29 20:34 keltezéssel, Michael Meskes írta:
On Thu, Mar 29, 2012 at 01:03:41PM -0400, Noah Misch wrote:
Still, we're looking at dedicated ECPG syntax, quite visible even to folks
with no interest in Informix. We have eschewed littering our syntax with
compatibility aids, and I like it
On Thu, Mar 29, 2012 at 8:04 AM, Andrew Dunstan and...@dunslane.net wrote:
1. I've been in discussion with some people about adding simple JSON extract
functions. We already have some (i.e. xpath()) for XML.
2. You might find htsql http://htsql.org/ interesting.
My colleagues and myself have
On Thu, Mar 29, 2012 at 12:57 PM, Daniel Farina dan...@heroku.com wrote:
D'oh, I munged the order.
More technical concerns:
* Protocol compression -- but a bit of sand in the gears is *which*
compression -- for database workloads, the performance of zlib can be
a meaningful bottleneck.
*
I wrote:
... PREPARE/EXECUTE work a bit funny though: if you have
track = all then you get EXECUTE cycles reported against both the
EXECUTE statement and the underlying PREPARE. This is because when
PREPARE calls parse_analyze_varparams the post-analyze hook doesn't know
that this isn't a
On Thu, Mar 29, 2012 at 4:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
... PREPARE/EXECUTE work a bit funny though: if you have
track = all then you get EXECUTE cycles reported against both the
EXECUTE statement and the underlying PREPARE. This is because when
PREPARE calls
On Fri, Mar 23, 2012 at 2:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
What I think is more common is the repeated submission of queries that
are *nearly* identical, but with either different parameter bindings
or different constants. It would be nice to
Robert Haas robertmh...@gmail.com writes:
Well, preceding and before are synonyms, so I don't see any advantage
in that change. But I really did mean AT permissions_checking time,
not before or after it. That is, we'd have a hook where instead of
doing something like this:
aclresult =
Robert Haas robertmh...@gmail.com writes:
Interestingly, Peter Geoghegan's blog post on the pg_stat_statements
patch you just committed[1] claims that the overhead of fingerprinting
queries was only 1-2.5%, which is less than I would have thought, so
if we ever get to the point where we're
Robert Haas robertmh...@gmail.com writes:
Apropos of nothing and since I haven't found a particularly good time
to say this in amidst all the technical discussion, I appreciate very
much all the work you've been putting into this.
Hey, thanks, I very much appreciate your support here!
(1) is
Kyotaro HORIGUCHI horiguchi.kyot...@oss.ntt.co.jp writes:
I'm sorry to have coded a silly bug.
The previous patch has a bug in realloc size calculation.
And separation of the 'connname patch' was incomplete in regtest.
It is fixed in this patch.
I've applied a modified form of the conname
On Thu, Mar 29, 2012 at 4:21 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
Well, preceding and before are synonyms, so I don't see any advantage
in that change. But I really did mean AT permissions_checking time,
not before or after it. That is,
Marko Kreen mark...@gmail.com writes:
My conclusion is that row-processor API is low-level expert API and
quite easy to misuse. It would be preferable to have something more
robust as end-user API, the PQgetRow() is my suggestion for that.
Thus I see 3 choices:
1) Push row-processor as main
On Thu, Mar 29, 2012 at 4:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It's also probably worth keeping in mind the next time we
bump the protocol version: it would be nice to have a way of doing
prepare-bind-execute in a single protocol message, which I believe to
be not possible at present.
On Thu, Mar 29, 2012 at 11:04 PM, Andrew Dunstan and...@dunslane.netwrote:
On 03/29/2012 10:37 AM, Dobes Vandermeer wrote:
Hi guys,
Something from Josh's recent blog post about summer of code clicked with
me - the HTTP / SQL concept.
1. I've been in discussion with some people about
On Thu, Mar 29, 2012 at 6:25 PM, Dobes Vandermeer dob...@gmail.com wrote:
2. You might find htsql http://htsql.org/ interesting.
As a reference, or should we just bundle / integrate that with PostgreSQL
somehow?
It's a totally different language layer without wide-spread popularity
and, as
On Fri, Mar 30, 2012 at 3:59 AM, Daniel Farina dan...@heroku.com wrote:
On Thu, Mar 29, 2012 at 12:57 PM, Daniel Farina dan...@heroku.com
wrote:
More technical concerns:
* Protocol compression -- but a bit of sand in the gears is *which*
compression -- for database workloads, the
On Fri, Mar 30, 2012 at 3:57 AM, Daniel Farina dan...@heroku.com wrote:
On Thu, Mar 29, 2012 at 8:04 AM, Andrew Dunstan and...@dunslane.net
wrote:
Lastly, a case that can not as easily be fixed without some more
thinking is leveraging caching semantics of HTTP. think people would
On tis, 2012-03-27 at 00:53 +0100, Greg Stark wrote:
Hm. So my original plan was dependent on adding the state-merge
function we've talked about in the past. Not all aggregate functions
necessarily can support such a function but I think all or nearly all
the builtin aggregates can. Certainly
On Thu, Mar 29, 2012 at 6:37 PM, Dobes Vandermeer dob...@gmail.com wrote:
On Fri, Mar 30, 2012 at 3:59 AM, Daniel Farina dan...@heroku.com wrote:
On Thu, Mar 29, 2012 at 12:57 PM, Daniel Farina dan...@heroku.com
wrote:
More technical concerns:
* Protocol compression -- but a bit of sand in
I've applied a modified form of the conname update patch. It seemed to
me that the fault is really in the DBLINK_GET_CONN and
DBLINK_GET_NAMED_CONN macros, which ought to be responsible for setting
the surrounding function's conname variable along with conn, rconn, etc.
There was actually a
On Fri, Mar 30, 2012 at 10:55 AM, Daniel Farina dan...@heroku.com wrote:
On Thu, Mar 29, 2012 at 6:37 PM, Dobes Vandermeer dob...@gmail.com
wrote:
On Fri, Mar 30, 2012 at 3:59 AM, Daniel Farina dan...@heroku.com
wrote:
On Thu, Mar 29, 2012 at 12:57 PM, Daniel Farina dan...@heroku.com
85 matches
Mail list logo
