Hello list,
My apologies if this email arrives more than once, I've been
experiencing troubles posting to the -hackers list and am resending this
review as new thread instead of a reply to an existing thread of
http://archives.postgresql.org/pgsql-hackers/2010-07/msg01072.php which
also has
Hi,
... Off the list I've received word from Zoltan
that work on a new patch is planned. It would be great if ideas from
both patches could be merged into one.
...
* Does it follow SQL spec, or the community-agreed behavior?
A: Unknown, though the choices in guc parameters suggest the
On 7/24/2010 1:43 AM, Robert Haas wrote:
On Fri, Jul 23, 2010 at 6:20 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
It seems like it's EXPLAIN ANALYZE that needs fixing.
I would suggest that if we're going to change this, we back-patch it
to 9.0 before beta4.
I did some digging and
Le 21/07/2010 09:53, Dave Page a écrit :
On Tue, Jul 20, 2010 at 8:12 PM, Peter Eisentraut pete...@gmx.net wrote:
My preference would be to stick to a style where we identify the
committer using the author tag and note the patch author, reviewers,
whether the committer made changes, etc. in
It looks good to me: (0) new patch applies cleanly to CVS HEAD; (1)
the formating of the code was changed; (2) definition of the HYPOT
macro was changed to use phypot rather than being removed; (3) the
phypot function was declared to be extern; (4) the comments to the
phypot function were changed
Hello Zoltán,
Thanks for your reply!
Instead, I will post a patch that unifies my configuration choices with
Fujii's patch.
Please know that Fujii's patch is also a work in progress. I didn't
mention in my review the previously discussed items, most important the
changing the polling loops
On fre, 2010-07-23 at 11:00 -0600, Alex Hunsaker wrote:
I just read that patch is getting pushed till at least the next commit
fest: http://archives.postgresql.org/pgsql-hackers/2010-07/msg01219.php
Should we push this patch back to? Alternatively we could make it
work with just primary
Hello Zoltán,
Thanks for your reply!
Instead, I will post a patch that unifies my configuration choices with
Fujii's patch.
Please know that Fujii's patch is also a work in progress.
Yes, I know that. But working from Fujii's last public patch
or from his GIT tree makes my patch easier to
Hi,
I'd like to release the last version of my experimental join order
algorithm (TwoPO - Two Phase Optimization [1]):
http://git.c3sl.ufpr.br/gitweb?p=lbd/ljqo.git;a=summary
This algorithm is not production-ready, but an experimental set of
ideas, which need to be refined and evaluated. As the
Robert Haas wrote:
If git had a place to store all the information we care about, that
would be fine...
There's no reviewer header, and there's no concept that a patch
might have come from the author (or perhaps multiple authors), but
then have been adjusted by one or more reviewers and
Hi,
On 07/23/2010 09:45 PM, Dimitri Fontaine wrote:
Yeah, I guess user daemons would have to be workers, not plugins you
want to load into the coordinator.
Okay.
On the other side, the background workers have a connection to exactly
one database. They are supposed to do work on that
Markus Wanner mar...@bluegap.ch writes:
For one, yes, I want to avoid having to start ones too often. I did look
into letting these background workers switch the database connection, but
that turned out not to be worth the effort.
Would you prefer a background worker that's not connected to a
On lör, 2010-07-24 at 07:02 -0700, Ron Mayer wrote:
Instead of squashing every patch into a single commit, what if it got
squashed into a perhaps 3 separate commits -- one as submitted, one
as reviewed, and one as re-written by the committer. History stays
linear; and you keep the most
Peter Eisentraut wrote:
On lör, 2010-07-24 at 07:02 -0700, Ron Mayer wrote:
Instead of squashing every patch into a single commit, what if it got
squashed into a perhaps 3 separate commits -- one as submitted, one
as reviewed, and one as re-written by the committer. History stays
linear;
On Sat, 2010-07-24 at 13:48 -0400, Andrew Dunstan wrote:
Yeah. Also, please bear in mind that our explicit aim here is to make
this change with a minimal disruption to existing work flows. So to all
those people who want to say Look, you can now do all these cool
things my answer is
On 21/07/10 08:33, Mike Fowler wrote:
Why is the first argument AexprConst instead of a_expr? The SQL
standard says it's a character string literal, but I think we can very
well allow arbitrary expressions.
Yes, it was AexprConst because of the specification. I also found that
using it solved
Update: I'm in the middle of cleaning up the JSON code (
http://git.postgresql.org/gitweb?p=json-datatype.git;a=summary if you
want to see the very latest ), so I haven't addressed all of the major
problems with it yet.
On Fri, Jul 23, 2010 at 2:34 PM, Robert Haas robertmh...@gmail.com wrote:
-
On Sat, Jul 24, 2010 at 06:57:18PM -0400, Joseph Adams wrote:
A particularly useful aspect of the JSON support is the ability to
convert PostgreSQL arrays to JSON arrays (using to_json ), as there
currently isn't any streamlined way to parse arrays in the PostgreSQL
format client-side (that I
On Jul 23, 2010, at 7:11 AM, Tom Lane wrote:
I can't help thinking that the JDBC driver must be being overly cute
if this breaks it ...
I was wondering the same thing when I first saw Kris' message. However, iff I
understand what JDBC is trying to achieve, I don't think I would call it
In src/include/mb/pg_wchar.h , there is a function unicode_to_utf8 ,
but no corresponding utf8_to_unicode . However, there is a static
function called utf2ucs that does what utf8_to_unicode would do.
I'd like this function to be available because the JSON code needs to
convert UTF-8 to and from
20 matches
Mail list logo
