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
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 found the commit that chang
Le 21/07/2010 09:53, Dave Page a écrit :
> On Tue, Jul 20, 2010 at 8:12 PM, Peter Eisentraut 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 the comm
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 t
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 (se
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 easi
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 reviewe
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 database
Markus Wanner 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 database, or
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 rel
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; a
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 i
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 wrote:
> - I was under the impre
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
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
"over
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 U
> I, for one, think it would be great if the JSON datatype were all in
> core :-) However, if and how much JSON code should go into core >is up for
> discussion. Thoughts, anyone?
>
in my opinion: As soon as possible. Spinning PostgreSQL as the
Ajax-enabled-database has many great uses.
Harald
On Fri, Jul 23, 2010 at 10:05 AM, Jaime Casanova wrote:
> On Thu, Jun 10, 2010 at 3:39 PM, Robert Haas wrote:
>>
>>
>> I believe that this patch will clear away one major obstacle to
>> implementing global temporary and unlogged tables: it enables us to be
>> sure of cleaning up properly after a
21 matches
Mail list logo