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
> 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
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
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
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
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 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
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
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 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
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
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
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,
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
> 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
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. I didn't
mention in my review the previously discussed items, most important the
changing the polling loops (se
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
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
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
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
21 matches
Mail list logo
