On 30 September 2014 07:27, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
On Mon, Sep 29, 2014 at 9:04 AM, Kohei KaiGai kai...@kaigai.gr.jp
wrote:
Do we need to match the prototype of wrapper function with callback?
Yes.
OK, I fixed up the patch part-2, to fit declaration of
On Wed, Oct 22, 2014 at 1:37 PM, David Rowley dgrowle...@gmail.com wrote:
I've had a bit of a look at this and here's a couple of things:
Thanks. Sorry I didn't back to you earlier, I almost forgot about the review.
/*
+* LIMIT clause can be removed if it's a positive constant
On 10/9/14 3:38 PM, Robert Haas wrote:
The problem is that running initdb --not-a-valid-option leaves $? set
to 256, as seems entirely unsurprising. After running the anonymous
block passed to it, Test::Builder::subtest calls Test::Build::finalize
which calls Test::Build::_ending, which sets
On 10/07/2014 01:57 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I don't much like the idea of doing an install/initdb/start for every
directory in src/bin, though. Can't we at least manage a single
installation directory for all these?
Peter had a patch to eliminate the
Andrew Dunstan and...@dunslane.net writes:
On 10/07/2014 01:57 PM, Tom Lane wrote:
Peter had a patch to eliminate the overhead of multiple subinstalls;
not sure where that stands, but presumably it would address your issue.
Is there any progress on this. I'm reluctant to add this to the
Hi
My idea is using new ArrayBuilder optimized for building multidimensional
arrays with own State type. I think so casting to ArrayBuildState is base
of our problems, so I don't would to do. Code in array_agg_* is simple,
little bit more complex code is in nodeSubplan.c. Some schematic changes
On 10/26/2014 12:29 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 10/07/2014 01:57 PM, Tom Lane wrote:
Peter had a patch to eliminate the overhead of multiple subinstalls;
not sure where that stands, but presumably it would address your issue.
Is there any progress on
On 10/16/2014 04:12 PM, Pavel Stehule wrote:
1. missing documentation
2. I miss more comments related to this functions. This code is
relative simple, but some more explanation can be welcome.
3. why these functions are marked as stable?
New patch:
Docs added, functions marked
Hi
I have a question,
what is expected result of null strip of
{a: {b: null, c, null} }
?
2014-10-26 19:59 GMT+01:00 Andrew Dunstan and...@dunslane.net:
On 10/16/2014 04:12 PM, Pavel Stehule wrote:
1. missing documentation
2. I miss more comments related to this functions. This code
On 10/26/2014 03:50 PM, Pavel Stehule wrote:
Hi
I have a question,
what is expected result of null strip of
{a: {b: null, c, null} }
?
Please remember not to top-post.
The above is not legal json, so the answer would be an error.
cheers
andrew
--
Sent via pgsql-hackers mailing list
On 26 October 2014 20:07, Andrew Dunstan and...@dunslane.net wrote:
On 10/26/2014 03:50 PM, Pavel Stehule wrote:
Hi
I have a question,
what is expected result of null strip of
{a: {b: null, c, null} }
?
Please remember not to top-post.
The above is not legal json, so the answer
I wrote:
Andrew Gierth and...@tao11.riddles.org.uk writes:
Bruce == Bruce Momjian br...@momjian.us writes:
Bruce Uh, did this ever get addressed?
It did not.
It dropped off the radar screen (I think I'd assumed the patch would
appear in the next commitfest, which it didn't unless I missed
2014-10-26 21:18 GMT+01:00 Andrew Dunstan and...@dunslane.net:
On 10/26/2014 04:14 PM, Thom Brown wrote:
On 26 October 2014 20:07, Andrew Dunstan and...@dunslane.net mailto:
and...@dunslane.net wrote:
On 10/26/2014 03:50 PM, Pavel Stehule wrote:
Hi
I have a
On 10/26/2014 04:14 PM, Thom Brown wrote:
On 26 October 2014 20:07, Andrew Dunstan and...@dunslane.net
mailto:and...@dunslane.net wrote:
On 10/26/2014 03:50 PM, Pavel Stehule wrote:
Hi
I have a question,
what is expected result of null strip of
{a: {b:
Andrew Dunstan and...@dunslane.net writes:
On 10/26/2014 12:29 PM, Tom Lane wrote:
The pathname length problem I noted in
http://www.postgresql.org/message-id/16477.1413831...@sss.pgh.pa.us
seems like a show-stopper as well, since undoubtedly a number of
buildfarm critters are using
On Sat, Oct 25, 2014 at 8:12 AM, Robert Haas robertmh...@gmail.com wrote:
Generating index paths for the UPDATE is a waste of cycles.
Theoretically, there could be an (a, b, c) unique index and a (c,b,a)
unique index, and those two might have a non-equal cost to scan. But
that almost certainly
I wrote:
More generally, it seems like we ought to have a test in the type_sanity
regression script that checks that type I/O functions aren't volatile,
...
Actually, the right thing to do if we want to enforce this is for
CREATE TYPE to check the marking. We'd still need a type_sanity
On 10/26/2014 04:22 PM, Pavel Stehule wrote:
2014-10-26 21:18 GMT+01:00 Andrew Dunstan and...@dunslane.net
mailto:and...@dunslane.net:
On 10/26/2014 04:14 PM, Thom Brown wrote:
On 26 October 2014 20:07, Andrew Dunstan and...@dunslane.net
mailto:and...@dunslane.net
Hi all,
currently, CREATE DATABASE forces an immediate checkpoint (actually, it
forces two, but the time interval is usually rather small). For
traditional deployments this is not a big deal, because creating a
database is a rare event, and may be planned to off-peak times.
However for shared
On Wed, Oct 22, 2014 at 12:12:36AM -0400, Noah Misch wrote:
On Mon, Oct 20, 2014 at 01:03:31AM -0400, Noah Misch wrote:
I reproduced narwhal's problem using its toolchain on another 32-bit Windows
Server 2003 system. The crash happens at the SHGetFolderPath() call in
pqGetHomeDirectory().
It seems the buffer created in pset_quoted_string is just 1 char too small.
This breaks psql's \pset for me, though I've no idea why the buildfarm is
not complaining a bit more.
As it stands, if the function is given an empty string to quote, it tries
to build a string with 2 single quotes and a
Noah Misch n...@leadboat.com writes:
Calls to ldap_init() exhibit the same problem shfolder.dll:SHGetFolderPath()
exhibited: it loads and unloads some DLLs, and it manages to unload libpq in
passing. There's nothing comparable to the above workaround this time, but I
found a more fundamental
Buildfarm member hamerkop has been failing in the pg_upgrade regression
test for the last several days. The problem looks like this:
command:
C:/buildfarm/build_root/HEAD/pgsql.build/contrib/pg_upgrade/tmp_check/install/bin/pg_restore
--port 50432 --username Administrator --exit-on-error
David Rowley dgrowle...@gmail.com writes:
It seems the buffer created in pset_quoted_string is just 1 char too small.
Yeah, that's a bug. Fix pushed, thanks!
This breaks psql's \pset for me, though I've no idea why the buildfarm is
not complaining a bit more.
I think in most cases, maxalign
Tatsuo Ishii wrote:
Buildfarm member hamerkop has been failing in the pg_upgrade regression
test for the last several days. The problem looks like this:
command:
C:/buildfarm/build_root/HEAD/pgsql.build/contrib/pg_upgrade/tmp_check/install/bin/pg_restore
--port 50432 --username
Alvaro Herrera alvhe...@2ndquadrant.com writes:
So this seems related to the %z part of the strftime() call. I have no
explanation for this failure ATM; maybe pg_restore is failing to set the
locale properly? I also notice pg_restore.c previously included
pg_backup_archiver.h (which in turn
I wrote:
Hm. %z ought not be locale-dependent ... however, it has a bigger
problem, which is that it's a C99-ism. It's not there in SUSv2,
which is our normal baseline for what's portable. I think we need
to get rid of that. %Z should be portable.
(Is it possible that Windows' strftime()
On Mon, Oct 27, 2014 at 1:56 AM, Marti Raudsepp ma...@juffo.org wrote:
On Wed, Oct 22, 2014 at 1:37 PM, David Rowley dgrowle...@gmail.com
wrote:
I've had a bit of a look at this and here's a couple of things:
Thanks. Sorry I didn't back to you earlier, I almost forgot about the
review.
On Mon, Oct 27, 2014 at 12:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
It seems the buffer created in pset_quoted_string is just 1 char too
small.
Yeah, that's a bug. Fix pushed, thanks!
Thanks for committing.
This breaks psql's \pset for me,
On 10/24/2014 06:07 PM, Robert Haas wrote:
I think instead of focusing on foreign keys, we should rewind a bit
and think about the locking level required to add a trigger.
Agreed.
As far as triggers are concerned, the issue of skew between the
transaction snapshot and what the ruleutils.c
2014-10-27 1:38 GMT+07:00 Pavel Stehule pavel.steh...@gmail.com:
Hi
My idea is using new ArrayBuilder optimized for building multidimensional
arrays with own State type. I think so casting to ArrayBuildState is base
of our problems, so I don't would to do. Code in array_agg_* is simple,
On 10/26/14, 3:46 PM, Tom Lane wrote:
I wrote:
More generally, it seems like we ought to have a test in the type_sanity
regression script that checks that type I/O functions aren't volatile,
...
Actually, the right thing to do if we want to enforce this is for
CREATE TYPE to check the
Thanks Kyotaro,
I just did quickly looked at the patch and it does cover more syntax then
earlier patch. But still if doesn't not cover the all the part of syntax
where
we can use CURRENT_USER/CURRENT_ROLE/USER/SESSION_USER. For example:
-- Not working
alter default privileges for role
33 matches
Mail list logo
