On 05/03/2015 11:20 PM, Dmitry Shirokov wrote:
Hi all,
Are there any plans to introduce in next versions of Postgres a schema
validation for JSON field type? It would be very nice to have a
support of something like json-schema spec, see
http://json-schema.org/documentation.html. Right now
On 05/03/2015 11:49 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 05/01/2015 07:24 PM, Josh Berkus wrote:
(A possible compromise position would be to offer a new GUC to
enable/disable the optimization globally; that would add only a reasonably
small amount of control code
On 05/01/2015 07:24 PM, Josh Berkus wrote:
O
(A possible compromise position would be to offer a new GUC to
enable/disable the optimization globally; that would add only a reasonably
small amount of control code, and people who were afraid of the change
breaking their apps would probably want
On 05/01/2015 10:14 AM, Bruce Momjian wrote:
Currently initdb outputs suggested text on starting the server:
Success. You can now start the database server using:
/u/pgsql/bin/postgres -D /u/pgsql/data
or
/u/pgsql/bin/pg_ctl -D /u/pgsql/data -l
On 05/01/2015 08:57 AM, Andrew Dunstan wrote:
On 04/30/2015 09:09 PM, Christian Ullrich wrote:
* Andrew Dunstan:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since Monday running
On 04/30/2015 09:09 PM, Christian Ullrich wrote:
* Andrew Dunstan:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since Monday running the plpython regression
tests. The only relevant commit
On 04/28/2015 12:03 PM, Andrew Dunstan wrote:
[switching to -hackers]
On 04/28/2015 11:51 AM, Andrew Dunstan wrote:
On 04/28/2015 09:04 AM, Michael Paquier wrote:
On Tue, Apr 28, 2015 at 10:01 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Tue, Apr 28, 2015 at 9:55 AM, Andrew
On 04/28/2015 04:31 PM, Peter Eisentraut wrote:
On 4/28/15 12:05 AM, Tom Lane wrote:
Yeah. Even more specifically, olinguito does have --with-python in its
configure flags, but then the plpython Makefile skips the build because
libpython isn't available as a shared library. But the contrib
Oops, thought I'd changed the address line.
[switching to -hackers]
On 04/28/2015 11:51 AM, Andrew Dunstan wrote:
On 04/28/2015 09:04 AM, Michael Paquier wrote:
On Tue, Apr 28, 2015 at 10:01 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Tue, Apr 28, 2015 at 9:55 AM, Andrew
On 04/28/2015 03:50 PM, Bruce Momjian wrote:
On Tue, Apr 28, 2015 at 12:46:22PM -0700, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I know COPY doesn't support importing files with fixed column widths,
i.e. we can't say field1 is the first 30 characters, and field2 is the
rest of
On 04/28/2015 01:44 PM, Jim Nasby wrote:
On 4/27/15 10:06 PM, Andrew Dunstan wrote:
My point remains that we really need methods of a) getting the field
names from generic records and b) using text values to access fields of
generic records, both as lvalues and rvalues. Without those
On 04/27/2015 02:39 AM, Michael Paquier wrote:
On Sat, Apr 25, 2015 at 11:36 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Sat, Apr 25, 2015 at 4:51 AM, Andrew Dunstan and...@dunslane.net wrote:
The optional buildfarm module that runs this test was broken by commit
On 04/27/2015 08:46 AM, Michael Paquier wrote:
On Mon, Apr 27, 2015 at 9:25 PM, Peter Eisentraut pete...@gmx.net wrote:
On 4/27/15 2:09 AM, Michael Paquier wrote:
2) I noticed that VC builds do not like *at all* file paths with
forward slashes, perhaps it could be possible to use a Condition
On 04/27/2015 12:46 PM, Petr Jelinek wrote:
Another thing I noticed now when reading the code again - you should
not be using braces when you only have one command in the code-block.
There's one exception I, at least, have to this rule, namely when
there's a corresponding compound if or
On 04/27/2015 10:35 PM, Jim Nasby wrote:
On 4/25/15 4:50 PM, Tom Lane wrote:
Well, we already support local variables of type RECORD in plpgsql, so
it's not immediately clear to me that function arguments would be much
worse. There are a lot of deficiencies with the RECORD-local-variable
On 04/26/2015 03:13 AM, Michael Paquier wrote:
Oops, attached is a patch that should make currawong happier..
OK, pushed.
Argh. This is not enough:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=currawongdt=2015-04-26%2006%3A00%3A01
The build is done in Debug mode, but it is failing
On 04/26/2015 04:08 PM, Noah Misch wrote:
On Sun, Apr 26, 2015 at 10:23:58AM -0400, Andrew Dunstan wrote:
Setting up a VS2008 environment is hard these days, as MS seems to have
removed the download :-(
Visual C++ 2008 Express Edition:
http://go.microsoft.com/?linkid=7729279
Oh, cool
On 04/25/2015 08:01 PM, Michael Paquier wrote:
On Sun, Apr 26, 2015 at 2:19 AM, Andrew Dunstan and...@dunslane.net wrote:
On 04/25/2015 10:53 AM, Michael Paquier wrote:
On Sat, Apr 25, 2015 at 9:58 PM, Peter Eisentraut wrote:
On 4/24/15 12:22 AM, Michael Paquier wrote:
Now that the stuff
On 04/25/2015 12:32 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 04/24/2015 06:41 PM, Tom Lane wrote:
Yeah, this was brought up when we added per-large-object metadata; it was
obvious that that patch would cause pg_dump to choke on large numbers of
large objects
On 04/25/2015 10:53 AM, Michael Paquier wrote:
On Sat, Apr 25, 2015 at 9:58 PM, Peter Eisentraut wrote:
On 4/24/15 12:22 AM, Michael Paquier wrote:
Now that the stuff related to the move from contrib/ to src/bin/,
modulescheck and tmp_install has been committed, shouldn't we give a
new shot
On 04/24/2015 06:41 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 04/23/2015 04:04 PM, Andrew Gierth wrote:
The relevant code is getBlobs in pg_dump.c, which queries the whole of
pg_largeobject_metadata without using a cursor (so the PGresult is
already huge thanks
The optional buildfarm module that runs this test was broken by commit
dcae5faccab64776376d354decda0017c648bb53
Since nobody has responded to my complaint about this, I have disabled it on
crake, the only buildfarm machine that has actually been running the test, so
we now have no buildfarm
On 04/23/2015 04:04 PM, Andrew Gierth wrote:
Joshua == Joshua D Drake j...@commandprompt.com writes:
Joshua The database dumps fine as long as we don't dump large
Joshua objects. However, if we try to dump the large objects, FreeBSD
Joshua will kill pg_dump as it will consume all free
On 04/22/2015 11:29 AM, Jim Nasby wrote:
On 4/20/15 2:04 PM, David G. Johnston wrote:
SELECT (src.v).* FROM ( VALUES (ROW(1,2,3)) ) src (v);
ERROR: record type has not been registered
While it may not be necessary to solve both problems I suspect they have
the same underlying root cause -
changed) at
https://raw.githubusercontent.com/PGBuildFarm/client-code/b80efc68c35ef8a1ced37b57b3d19a98b8ae5dd2/run_build.pl
Sorry for the inconvenience.
cheers
andrew
On 04/17/2015 10:33 AM, Andrew Dunstan wrote:
I have just released version 4.15 of the PostgreSQL Buildfarm Client
http
I have just released version 4.15 of the PostgreSQL Buildfarm Client
http://www.pgbuildfarm.org/downloads/releases/build-farm-4_15.tgz. It
can be downloaded at
http://www.pgbuildfarm.org/downloads/releases/build-farm-4_15.tgz
Here's what's changed:
* support the new location for pg_upgrade
On 04/16/2015 02:46 AM, Michael Paquier wrote:
Hi all,
As mentioned previously
(cab7npqscphafxs2rzeb-fbccjqiknqxjhloztkggim1mf5x...@mail.gmail.com),
attached are patches to add support for src/test/modules in MSVC
builds, modules whose tests are not supported since they have been
moved from
On 04/16/2015 07:42 PM, Michael Paquier wrote:
Then if all goes well we can apply the third patch and I'll fix the
buildfarm client for the forthcoming release to run the tests on MSVC
builds. Nothing will break in the meantime - the tests just won't get
run until the new client version is
On 04/15/2015 10:51 AM, Andrew Dunstan wrote:
On 04/15/2015 08:31 AM, Michael Paquier wrote:
On Wed, Apr 15, 2015 at 7:54 PM, Peter Eisentraut pete...@gmx.net
wrote:
On 4/14/15 8:32 PM, Peter Eisentraut wrote:
Move pg_upgrade from contrib/ to src/bin/
Oh dear. It appears the buildfarm
On 04/15/2015 08:31 AM, Michael Paquier wrote:
On Wed, Apr 15, 2015 at 7:54 PM, Peter Eisentraut pete...@gmx.net wrote:
On 4/14/15 8:32 PM, Peter Eisentraut wrote:
Move pg_upgrade from contrib/ to src/bin/
Oh dear. It appears the buildfarm client code needs to be updated to
support this.
On 04/15/2015 12:23 PM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
OK, the fix is here:
https://github.com/PGBuildFarm/client-code/commit/47b24efa758360699413640dd14c4096e1643fb2
and the new TestUpgrade.pm can be grabbed from here:
https://raw.githubusercontent.com/PGBuildFarm/client-code
On 04/11/2015 07:30 PM, Andrew Dunstan wrote:
On 04/11/2015 05:10 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I have just noticed something slightly odd. The traces (obtained by
setting client_min_messages to debug1) from the blackhole FDW show that
the handler function
I have just noticed something slightly odd. The traces (obtained by
setting client_min_messages to debug1) from the blackhole FDW show that
the handler function is called each time an INSERT is performed. This is
not the case for SELECT, UPDATE or DELETE. It looks at first glance like
a
On 04/11/2015 05:10 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I have just noticed something slightly odd. The traces (obtained by
setting client_min_messages to debug1) from the blackhole FDW show that
the handler function is called each time an INSERT is performed
On 04/11/2015 07:30 PM, Andrew Dunstan wrote:
On 04/11/2015 05:10 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I have just noticed something slightly odd. The traces (obtained by
setting client_min_messages to debug1) from the blackhole FDW show that
the handler function
On 04/09/2015 09:09 AM, Magnus Hagander wrote:
Moved is really only applicable, I think, for cases where we punt a
patch to the next CF for lack of time.
Well, that's basically what returned with feedback is now, so I
guess that one should just be renamed in that case. And we add
On 04/08/2015 03:28 PM, Magnus Hagander wrote:
On Wed, Apr 8, 2015 at 4:57 AM, Robert Haas robertmh...@gmail.com
mailto:robertmh...@gmail.com wrote:
On Tue, Apr 7, 2015 at 3:35 PM, Peter Eisentraut pete...@gmx.net
mailto:pete...@gmx.net wrote:
On 4/7/15 3:33 PM, Tom Lane wrote:
On 04/04/2015 10:27 AM, Tom Lane wrote:
Andrew Gierth and...@tao11.riddles.org.uk writes:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom ... btw, has anyone noticed that this patch broke hamerkop and
Tom bowerbird? Or at least, it's hard to see what other recent commit
Tom would explain
On 04/04/2015 04:27 PM, Robert Haas wrote:
On Sat, Apr 4, 2015 at 10:27 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I see nothing in the win32 stuff that tries to define USE_FLOAT8_BYVAL
on 64-bit windows, is this just an oversight or does it not actually
work there? or is it for on-disk
On 04/02/2015 12:42 PM, Alvaro Herrera wrote:
David Fetter wrote:
I haven't checked yet, but could this be because people aren't using
--enable-depend with ./configure ?
BTW --- No, this can't be the answer; --enable-depend is meant to help
with recompiling after updating the source tree,
On 03/31/2015 04:48 PM, Tom Lane wrote:
In view of that, you could certainly argue that if someone's bothered
to make a patch to add a new regFOO type, it's useful enough. I don't
want to end up with thirtysomething of them, but we don't seem to be
trending in that direction.
Or in short,
On 04/01/2015 12:53 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 04/01/2015 12:13 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The only possible issue I see on reading the patches is that these are
treated differently for dependencies than other regFOO
On 04/01/2015 12:13 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The only possible issue I see on reading the patches is that these are
treated differently for dependencies than other regFOO types. Rather
than create a dependency if a value is used in a default expression
On 03/29/2015 02:55 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I have just claimed this as committer in the CF, but on reviewing the
emails it looks like there is disagreement about the need for it at all,
especially from Tom and Robert.
I confess I have often wanted
On 03/10/2015 04:42 AM, Kyotaro HORIGUCHI wrote:
Thank you for the correction.
At Wed, 4 Mar 2015 01:01:48 -0600, Jim Nasby jim.na...@bluetreble.com wrote in
54f6addc.8030...@bluetreble.com
On 3/3/15 8:04 PM, Kyotaro HORIGUCHI wrote:
Note: The OID alias types don't sctrictly comply the
On 12/21/2014 02:22 PM, Andrew Dunstan wrote:
On 11/15/2014 05:56 PM, Andrew Dunstan wrote:
On 11/13/2014 11:41 AM, Andrew Dunstan wrote:
On 11/13/2014 11:09 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I often get annoyed because psql is a bit too aggressive when
On 03/26/2015 11:10 AM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Without having actually tried it, it looks clean enough to me. If
there's more pager options we might at some point introduce a pager
options struct instead adding more options to PageOutput. But for now it
On 03/26/2015 11:10 AM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Without having actually tried it, it looks clean enough to me. If
there's more pager options we might at some point introduce a pager
options struct instead adding more options to PageOutput. But for now it
On Mon, Mar 16, 2015 at 11:46 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Mar 15, 2015 at 8:04 PM, Rui DeSousa r...@crazybean.net wrote:
Would a parameter to auto terminate long running transactions be a
better solution? Terminating the long running transaction would allow for
the
On 03/15/2015 02:12 PM, Andres Freund wrote:
Hi,
On 2015-03-15 14:03:08 -0400, Tom Lane wrote:
Buildfarm member brolga seems unhappy with my commit 91f4a5a that
restricted port/dirmod.c to being built only on Windows. Evidently
we need to build it when $PORTNAME = cygwin as well, which is
On 03/14/2015 06:04 PM, Tom Lane wrote:
Given the rather hostile response I got to
http://www.postgresql.org/message-id/4146.1425872...@sss.pgh.pa.us
I was not planning to bring this topic up again until 9.6 development
starts. However, as I said in that thread, this work is getting done now
On 03/09/2015 11:31 AM, Michael Meskes wrote:
Actually, if we are supporting toolchains that generate *.obj files,
I'd expect the top-level .gitignore to ignore them, as it does *.o.
But if that's the issue why have we not heard complaints before?
...
+1 for adding a top level .gitignore
On 03/09/2015 09:46 AM, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Michael Paquier wrote:
When running the test suite of ecpg, build generates a set of obj
files and it happens that those files are not ignored in the code
tree.
Wouldn't this be simpler as a *.obj pattern
On 03/08/2015 10:11 PM, Alvaro Herrera wrote:
Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
And even if it turns out to actually be bothersome, you can help
yourself by passing -U 5/setting diff.context = 5 or something like
that.
Um. Good luck with getting every patch
On 03/07/2015 05:46 PM, Andres Freund wrote:
On 2015-03-07 16:43:15 -0600, Jim Nasby wrote:
Semi-related... if we put some special handling in some places for bootstrap
mode, couldn't most catalog objects be created using SQL, once we got
pg_class, pg_attributes and pg_type created? That would
On 03/04/2015 10:28 PM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 2/13/15 10:20 AM, Teodor Sigaev wrote:
Some of users of intarray contrib module wish to use its features with
another kind of arrays, not only for int4 type. Suggested module
generalizes intarray over other
On 03/04/2015 10:37 PM, Peter Eisentraut wrote:
On 2/15/15 6:55 AM, Michael Paquier wrote:
I tested quickly the second patch with MS 2010 and I am getting a
build failure: chkpass cannot complete because of crypt missing. On
master build passes. More details here:
On 03/04/2015 09:42 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 3/3/15 9:49 PM, Robert Haas wrote:
Even this promises to vastly increase the number of lines in the file,
I think lines are cheap. Columns are much harder to deal with.
Yeah. pg_proc.h is already
On 03/04/2015 09:51 AM, Robert Haas wrote:
On Wed, Mar 4, 2015 at 9:06 AM, Peter Eisentraut pete...@gmx.net wrote:
and make it harder to compare entries by grepping out some common
substring.
Could you give an example of the sort of thing you wish to do?
e.g. grep for a function name and
On 03/01/2015 05:03 AM, Petr Jelinek wrote:
On 23/02/15 18:15, Dmitry Dolgov wrote:
Hi, Petr, thanks for the review.
I think it would be better if the ident printing didn't put the
start of array ([) and start of dictionary ({) on separate line
Did you mean this?
[
{
On 02/25/2015 11:59 AM, Joe Conway wrote:
It's largely because of such uncertainties that I have been advised
in the past (by those with appropriate letters after their names)
to stop using the Artistic licence. This is why I spent nearly a
year working on changing pgAdmin to the PostgreSQL
On 02/25/2015 06:44 PM, Jim Nasby wrote:
On 2/25/15 4:10 PM, Andrew Dunstan wrote:
On 02/25/2015 11:59 AM, Joe Conway wrote:
It's largely because of such uncertainties that I have been advised
in the past (by those with appropriate letters after their names)
to stop using the Artistic
On 02/22/2015 11:48 AM, Kevin Grittner wrote:
(2) Use a course enough granularity on time and a short enough
maximum for the GUC to just keep a circular buffer of the mappings
in memory. We might be able to make this dense enough that one
minute resolution for up to 60 days could fit in
On 02/21/2015 09:39 AM, Andrew Dunstan wrote:
On 02/21/2015 05:04 AM, Andres Freund wrote:
Yes, that's a good point. I have zero desire to open-code a format
though, I think that's a bad idea. We could say we just include
Yaml::Tiny, that's what it's made for.
Personally, I think I would
On 02/21/2015 11:43 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 02/21/2015 09:39 AM, Andrew Dunstan wrote:
Personally, I think I would prefer that we use JSON (and yes, there's
a JSON::Tiny module, which definitely lives up to its name).
For one thing, we've made
On 02/21/2015 05:04 AM, Andres Freund wrote:
Yes, that's a good point. I have zero desire to open-code a format
though, I think that's a bad idea. We could say we just include
Yaml::Tiny, that's what it's made for.
Personally, I think I would prefer that we use JSON (and yes, there's a
On 02/16/2015 09:05 PM, Petr Jelinek wrote:
On 17/02/15 02:57, Andrew Dunstan wrote:
On 02/16/2015 08:48 PM, Petr Jelinek wrote:
On 17/02/15 01:57, Peter Geoghegan wrote:
On Mon, Feb 16, 2015 at 4:44 PM, Petr Jelinek p...@2ndquadrant.com
wrote:
We definitely want this feature, I wished
On 02/19/2015 03:31 PM, Kevin Grittner wrote:
What about having the long running snapshots declare their working
set, and then only take them into account for global xmin for
relations that are in the working set? Like a SET TRANSACTION WORKING
SET command. This way the error is deterministic,
On 02/19/2015 09:44 AM, Kevin Grittner wrote:
On the 15th I said this:
| What this discussion has made me reconsider is the metric for
| considering a transaction too old. The number of transaction IDs
| consumed seems inferior as the unit of measure for that to LSN or
| time.
|
| It looks
On 02/17/2015 08:21 PM, Peter Eisentraut wrote:
On 1/20/15 6:32 PM, David G Johnston wrote:
In fact, as far as
the database knows, the values provided to this function do represent an
entire population and such a correction would be unnecessary. I guess it
boils down to whether future queries
On 02/18/2015 08:34 PM, David Fetter wrote:
On Tue, Feb 17, 2015 at 08:21:32PM -0500, Peter Eisentraut wrote:
On 1/20/15 6:32 PM, David G Johnston wrote:
In fact, as far as the database knows, the values provided to this
function do represent an entire population and such a correction
would
On 02/16/2015 08:48 PM, Petr Jelinek wrote:
On 17/02/15 01:57, Peter Geoghegan wrote:
On Mon, Feb 16, 2015 at 4:44 PM, Petr Jelinek p...@2ndquadrant.com
wrote:
We definitely want this feature, I wished to have this info many times.
I would still like to see a benchmark.
Average of 3
On 02/16/2015 09:07 PM, Tom Lane wrote:
I wrote:
We have some code in the server that attempts to match IPv4 address
entries in pg_hba.conf to incoming connections that are in IPv6 protocol
but have addresses in the range :::: (the IPv4-in-IPv6
subrange). As revealed by today's
On 02/16/2015 08:57 PM, Andrew Dunstan wrote:
On 02/16/2015 08:48 PM, Petr Jelinek wrote:
On 17/02/15 01:57, Peter Geoghegan wrote:
On Mon, Feb 16, 2015 at 4:44 PM, Petr Jelinek p...@2ndquadrant.com
wrote:
We definitely want this feature, I wished to have this info many
times.
I would
On 02/15/2015 11:47 AM, Sehrope Sarkuni wrote:
For jsonb_indent, how about having it match up closer to the
JavaScript JSON.stringify(value, replacer, space)[1]? That way a user
can specify the indentation level and optionally filter the fields
they'd like to output.
In JS, the replacer
On 02/14/2015 10:06 PM, Andrew Dunstan wrote:
Attached is a patch to provide a number of very useful facilities to
jsonb that people have asked for. These are based on work by Dmitry
Dolgov in his jsonbx extension, but I take responsibility for any bugs.
The facilities are:
new operations
Attached is a patch to provide a number of very useful facilities to
jsonb that people have asked for. These are based on work by Dmitry
Dolgov in his jsonbx extension, but I take responsibility for any bugs.
The facilities are:
new operations:
concatenation:jsonb || jsonb - jsonb
On 12/18/2014 06:05 PM, Andrew Dunstan wrote:
On 12/18/2014 03:02 AM, Michael Paquier wrote:
On Fri, Dec 12, 2014 at 10:45 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Another thing in that patch was that I had to add the sql/ directory to
the source tree, but other than
On 02/03/2015 10:00 AM, David Fetter wrote:
On Tue, Feb 03, 2015 at 09:08:45AM -0500, Andrew Dunstan wrote:
On 02/03/2015 08:55 AM, Kevin Grittner wrote:
I run `make -s -j4 world` on my i7 fairly often, and it is often
the doc build that I wind up waiting for at the end.
I realize
On 02/04/2015 06:53 PM, Tom Lane wrote:
Or maybe use a make variable, like NO_DOC. I think that's preferable to
adding more targets.
Unless we can come up with a new target name that obviously means
world minus docs, the make-variable idea may be the best.
I'm not
On 02/03/2015 08:55 AM, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
On 02/02/2015 05:39 PM, Peter Eisentraut wrote:
I share the sentiment that the release notes *seem* too big, but the
subsequent discussion shows that it's not clear why
On 01/30/2015 11:00 AM, Tom Lane wrote:
I do see that macque is having issues, but it's been busted for the past
3 days it looks like.
Yeah. Several of the critters have been having git issues for weeks
to months. I wonder whether we couldn't teach the buildfarm script
to recover from this
On 01/29/2015 12:26 AM, Josh Berkus wrote:
So, for my 2c, I'm on the fence about it. On the one hand, I agree,
it's a bit of a complex process to get right. On the other hand, it's
far better if we put something out there along the lines of if you
really want to, this is how to do it than
On 01/29/2015 11:34 AM, Bruce Momjian wrote:
On Thu, Jan 29, 2015 at 10:21:30AM -0500, Andrew Dunstan wrote:
On 01/29/2015 12:26 AM, Josh Berkus wrote:
So, for my 2c, I'm on the fence about it. On the one hand, I agree,
it's a bit of a complex process to get right. On the other hand, it's
On 01/29/2015 04:59 PM, Robert Haas wrote:
On Thu, Jan 29, 2015 at 4:33 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/29/2015 12:10 PM, Robert Haas wrote:
On Wed, Jan 28, 2015 at 12:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The cause of this bug is commit
On 01/29/2015 12:10 PM, Robert Haas wrote:
On Wed, Jan 28, 2015 at 12:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The cause of this bug is commit 0ad1a816320a2b539a51628e2a0b1e83ff096b1d,
which I'm inclined to think we need to simply revert, not render even
more squirrely.
Yes, that commit
On 01/29/2015 05:39 PM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I have yet to understand what we fix by banning \u. How is
different from any other four-digit hexadecimal number that's not a
valid character in the current encoding? What does banning that one
On 01/28/2015 12:50 AM, Noah Misch wrote:
On Tue, Jan 27, 2015 at 03:56:22PM -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 01/27/2015 02:28 PM, Tom Lane wrote:
Well, we can either fix it now or suffer with a broken representation
forever. I'm not wedded to the exact
is the ability to gate auth by network and user, that being what
pg_hba.conf allows.
A conversation with Andrew Dunstan since I posted convinced me that
the amount of work to separate this cleanly and have it perform
somewhere in the close range of as well as it does now could be pretty
significant
On 01/27/2015 02:28 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 01/27/2015 01:40 PM, Tom Lane wrote:
In particular, I would like to suggest that the current representation of
\u is fundamentally broken and that we have to change it, not try to
band-aid around
On 01/27/2015 01:40 PM, Tom Lane wrote:
In particular, I would like to suggest that the current representation of
\u is fundamentally broken and that we have to change it, not try to
band-aid around it. This will mean an on-disk incompatibility for jsonb
data containing U+, but
On 01/27/2015 12:24 AM, Noah Misch wrote:
For the moment, maybe I could commit the fix for the non U+ case for
escape_json, and we could think some more about detecting and warning about
the problem strings.
+1 for splitting development that way. Fixing the use of escape_json() is
On 01/27/2015 12:23 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 01/27/2015 12:24 AM, Noah Misch wrote:
+1 for splitting development that way. Fixing the use of escape_json() is
objective, but the choices around the warning are more subtle.
OK, so something like
On 01/23/2015 02:18 AM, Noah Misch wrote:
On Wed, Jan 21, 2015 at 06:51:34PM -0500, Andrew Dunstan wrote:
The following case has just been brought to my attention (look at the
differing number of backslashes):
andrew=# select jsonb '\\u';
jsonb
--
\u
On 01/23/2015 03:00 PM, Alvaro Herrera wrote:
Why is the last; still there? AFAICS it matters in the old coding
because of the while, but I don't think there is an equivalent looping
construct in the new code.
You're right, I missed that. It shouldn't be there, and will produce an
error
On 01/23/2015 03:17 AM, Abhijit Menon-Sen wrote:
At 2014-06-03 22:30:50 -0400, pete...@gmx.net wrote:
I'm not sure whether the following coding actually detects any errors:
Solution.pm:
open(P, cl /? 21 |) || die cl command not found;
Since nobody with a Windows system has commented,
On 01/21/2015 11:21 AM, Arne Scheffer wrote:
Why is it a bad thing to call the column stddev_samp analog to the
aggregate function or make a note in the documentation, that the
sample stddev is used to compute the solution?
I think you are making a mountain out of a molehill, frankly.
On 01/21/2015 09:27 AM, Arne Scheffer wrote:
Sorry, corrected second try because of copypaste mistakes:
VlG-Arne
Comments appreciated.
Definition var_samp = Sum of squared differences /n-1
Definition stddev_samp = sqrt(var_samp)
Example N=4
1.) Sum of squared differences
1_4Sum(Xi-XM4)²
=
On 01/19/2015 09:53 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
But I'm wondering if we should look at using the tricks git-new-workdir
uses, setting up symlinks instead of a full clone. Then we'd have one
clone with a bunch of different work dirs. That plus
On 01/20/2015 01:26 PM, Arne Scheffer wrote:
Interesting patch.
I did a quick review looking only into the patch file.
The sum of variances variable contains
the sum of squared differences instead, I think.
Umm, no. It's not.
e-counters.sum_var_time +=
(total_time - old_mean) *
701 - 800 of 8267 matches
Mail list logo
