On 02/25/2014 08:23 AM, Haribabu Kommi wrote:
It's regarding a Todo item of Bit data type header reduction in some
cases. The header contains two parts. 1) The varlena header is
automatically converted to 1 byte header from 4 bytes in case of small
data. 2) The bit length header called bit_len
Hello.
May I mark this patch as Ready for Committer by myself since
this was already marked so in last CF3 and have had no objection
or new suggestion in this CF4 for more than a month?
At Tue, 14 Jan 2014 18:08:10 +0900, Kyotaro HORIGUCHI wrote
Hello, since CF4 is already closed but this patch
On 02/25/2014 06:52 AM, Michael Paquier wrote:
On Tue, Feb 25, 2014 at 10:02 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
(Not that it's this patch' responsibility to do that.)
Definitely a different patch.
Don't you think that this would break existing applications?
I hope there are
On Sun, Feb 23, 2014 at 6:54 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Folks,
Let me remind the custom-scan patches; that is a basis feature of
remote join of postgres_fdw, cache-only scan, (upcoming) GPU
acceleration feature or various alternative ways to scan/join relations.
Hi, I saw this patch has been moved into committed patches but
only the first part (0001_..) for the core is committed as of
32001ab but the rest for extension side seem not to have been
committed.
Would you mind taking a look on that, Álvaro?
regards,
At Wed, 22 Jan 2014 17:28:27 +0900,
On 25 Feb 2014 08:54, Heikki Linnakangas hlinnakan...@vmware.com wrote:
I hope there are no applications relying on pageinspect. It's a very
low-level tool. Or if someone has written a nice GUI around it, I'd like to
hear about it so that I can start using it :-).
I see more flexibility to
Sorry for jumping into this late.
Instead of custom node, it might be better idea to improve FDW infrastructure
to push join. For the starters, is it possible for the custom scan node
hooks to create a ForeignScan node? In general, I think, it might be better
for the custom scan hooks to
Hi,
Recently we observed below errors while taking dump after upgrading from
9.0.13 to 9.1.9.
pg_dump: schema with OID 0 does not exist
I referred similar issues reported previously (
http://www.postgresql.org/message-id/CAGWYGjXRJj=zugejv0ckvn4zf9hb92q+7e3aqfcvbgbmb9z...@mail.gmail.com)
and
Hello
2014-02-24 21:31 GMT+01:00 Jeff Janes jeff.ja...@gmail.com:
On Mon, Feb 24, 2014 at 7:02 AM, Pavel Stehule pavel.steh...@gmail.comwrote:
2014-02-23 21:32 GMT+01:00 Andres Freund and...@2ndquadrant.com:
Hi,
On 2014-02-23 20:04:39 +0100, Pavel Stehule wrote:
There is relative
In addition to an issue pointed out recently by Horiguchi-san, I've
found there is another issue we have to discuss. That is, we can't
build any parameterized Append paths for an inheritance tree that
contains at least one foreign table, in set_append_rel_pathlist(). This
is because the patch
On Tue, Feb 25, 2014 at 3:39 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Sorry for jumping into this late.
Instead of custom node, it might be better idea to improve FDW
infrastructure
to push join. For the starters, is it possible for the custom scan node
hooks to create a
On Feb24, 2014, at 17:50 , Dean Rasheed dean.a.rash...@gmail.com wrote:
On 20 February 2014 01:48, Florian Pflug f...@phlo.org wrote:
On Jan29, 2014, at 13:45 , Florian Pflug f...@phlo.org wrote:
In fact, I'm
currently leaning towards just forbidding non-strict forward transition
function
Also keep in mind that the system doesn't always retain the typmod. So the
datum should be possible to interpret without the typmod. Incidental
effects such as length limits or precision displayed are ok but the meaning
shouldn't be changed.
--
greg
On 24 Feb 2014 20:34, Tom Lane
Thx Tom!!
Yep, I focused on all trigonometric functions take arguments and return
values of type double precision. Looking for the error I lost focus on
numeric values directly on the select and diff inner calculations.
I think best approach will be maintain double precision on trigonometric
Hi,
On 01/28/2014 06:46 PM, Atri Sharma wrote:
On Tue, Jan 28, 2014 at 11:04 PM, Thom Brown t...@linux.com
mailto:t...@linux.com wrote:
Hi all,
Application to Google Summer of Code 2014 can be made as of next
Monday (3rd Feb), and then there will be a 12 day window in which to
Hello, All!
eshkin...@gmail.com writes:
create function perl_test(IN data text, OUT v1 text, OUT v2 integer, OUT v3
integer, OUT v4 json, OUT v5 json)
returns record as
$BODY$
use strict;
use warnings;
my $res-{'v1'} = 'content';
return $res;
$BODY$
language plperlu volatile
2014-02-25 20:32 GMT+09:00 Ashutosh Bapat ashutosh.ba...@enterprisedb.com:
On Tue, Feb 25, 2014 at 3:39 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Sorry for jumping into this late.
Instead of custom node, it might be better idea to improve FDW
infrastructure
to push join. For the
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 02/25/2014 08:23 AM, Haribabu Kommi wrote:
It's regarding a Todo item of Bit data type header reduction in some
cases. The header contains two parts. 1) The varlena header is
automatically converted to 1 byte header from 4 bytes in case of
Awesome. I can be an assistant mentor for this one is possible or I could
mentor some other project.
On Tuesday, February 25, 2014, Andreas 'ads' Scherbaum
adsm...@wars-nicht.de wrote:
Hi,
On 01/28/2014 06:46 PM, Atri Sharma wrote:
On Tue, Jan 28, 2014 at 11:04 PM, Thom Brown
On Mon, Feb 24, 2014 at 1:15 PM, Andrew Dunstan and...@dunslane.net wrote:
On 02/24/2014 11:06 AM, Merlin Moncure wrote:
On Mon, Feb 24, 2014 at 9:08 AM, Merlin Moncure mmonc...@gmail.com
wrote:
On Mon, Feb 24, 2014 at 8:46 AM, Merlin Moncure mmonc...@gmail.com
wrote:
I still find the
2014-02-25 11:29 GMT+01:00 Pavel Stehule pavel.steh...@gmail.com:
Hello
2014-02-24 21:31 GMT+01:00 Jeff Janes jeff.ja...@gmail.com:
On Mon, Feb 24, 2014 at 7:02 AM, Pavel Stehule pavel.steh...@gmail.comwrote:
2014-02-23 21:32 GMT+01:00 Andres Freund and...@2ndquadrant.com:
Hi,
On
On 1/30/14, 2:28 AM, Christian Kruse wrote:
after I finally got documentation compilation working I updated the
patch to be syntactically correct. You will find it attached.
I don't think we should be explaining the basics of OS memory management
in our documentation. And if we did, we
On 2014-02-25 10:45:55 -0500, Robert Haas wrote:
On Fri, Feb 14, 2014 at 7:05 AM, Andres Freund and...@2ndquadrant.com wrote:
In WalSndLoop() we do:
wakeEvents = WL_LATCH_SET | WL_POSTMASTER_DEATH | WL_TIMEOUT |
WL_SOCKET_READABLE;
if (pq_is_send_pending())
On Fri, Feb 14, 2014 at 7:05 AM, Andres Freund and...@2ndquadrant.com wrote:
In WalSndLoop() we do:
wakeEvents = WL_LATCH_SET | WL_POSTMASTER_DEATH | WL_TIMEOUT |
WL_SOCKET_READABLE;
if (pq_is_send_pending())
wakeEvents |= WL_SOCKET_WRITEABLE;
else if
On 2014-02-25 10:29:32 -0500, Peter Eisentraut wrote:
On 1/30/14, 2:28 AM, Christian Kruse wrote:
after I finally got documentation compilation working I updated the
patch to be syntactically correct. You will find it attached.
I don't think we should be explaining the basics of OS memory
Hi,
On 25/02/14 10:29, Peter Eisentraut wrote:
I don't think we should be explaining the basics of OS memory management
in our documentation.
Well, I'm confused. I thought that's exactly what has been asked.
And if we did, we shouldn't copy it verbatim from the Debian wiki
without
Hi,
On 25/02/14 17:01, Andres Freund wrote:
And if we did, we shouldn't copy it verbatim from the Debian wiki
without attribution.
Is it actually? A quick comparison doesn't show that many similarities?
Christian?
Not as far as I know. But of course, as I wrote the text I _also_
(that's
On Mon, Feb 24, 2014 at 12:31 PM, Josh Berkus j...@agliodbs.com wrote:
Aside from that, I want our docs to make a strong endorsement of using
jsonb over json for most users. jsonb will continue to be developed and
improved in the future; it is very unlikely that json will. Maybe
that's what
On Tue, Feb 25, 2014 at 10:54 AM, Andres Freund and...@2ndquadrant.com wrote:
I am not sure I can follow. Why doesn't it make sense to send out the
keepalive (with replyRequested = true) when we're busy sending stuff
(which will be the case most of the time on a busy server)?
It may very well
On 2014-02-25 11:15:46 -0500, Robert Haas wrote:
On Tue, Feb 25, 2014 at 10:54 AM, Andres Freund and...@2ndquadrant.com
wrote:
I am not sure I can follow. Why doesn't it make sense to send out the
keepalive (with replyRequested = true) when we're busy sending stuff
(which will be the case
On Tue, Feb 25, 2014 at 11:23 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-25 11:15:46 -0500, Robert Haas wrote:
On Tue, Feb 25, 2014 at 10:54 AM, Andres Freund and...@2ndquadrant.com
wrote:
I am not sure I can follow. Why doesn't it make sense to send out the
keepalive (with
On Mon, Feb 24, 2014 at 1:05 PM, Bruce Momjian br...@momjian.us wrote:
On Mon, Feb 17, 2014 at 11:14:33AM -0500, Bruce Momjian wrote:
On Sun, Feb 16, 2014 at 09:26:47PM -0500, Robert Haas wrote:
So, would anyone like me to create patches for any of these items before
we hit 9.4 beta? We
On Sat, Feb 22, 2014 at 7:02 PM, Rukh Meski rukh.me...@yahoo.ca wrote:
Sorry, I wanted to minimize the attention my message attracts. I mostly
posted it to let people know I plan on working on this for 9.5 to avoid
duplicated effort. I will post more documentation and my reasons for wanting
On Mon, Feb 24, 2014 at 2:11 AM, Mohsen SM mohsensoodk...@gmail.com wrote:
when did use varchar_transform function?
src/backend/uitls/adt/varchar.c.
The main point of that machinery is that if you do something like
ALTER TABLE zot ALTER COLUMN thunk SET DATA TYPE varchar(30) on a
column that is
On 2/25/14, 11:08 AM, Christian Kruse wrote:
Hi,
On 25/02/14 17:01, Andres Freund wrote:
And if we did, we shouldn't copy it verbatim from the Debian wiki
without attribution.
Is it actually? A quick comparison doesn't show that many similarities?
Christian?
Not as far as I know. But
On Mon, Feb 24, 2014 at 2:49 PM, Christian Kruse
christ...@2ndquadrant.com wrote:
attached you will find a fixed version.
Committed, after fixing the regression test outputs. I also changed
the new fields to be NULL rather than 0 when they are invalid, because
that way applying age() to that
On 02/25/2014 08:13 AM, Robert Haas wrote:
I think you've got your head stuck deeply in the sand. The json data
type works exactly like the xml data type has always worked. There
have been occasional noises about making an xmlb data type, but
nobody's minded enough to do anything about it,
On Tue, Feb 25, 2014 at 09:38:50AM -0800, Josh Berkus wrote:
In short, I think you're viewing everything about jsonb with
rose-colored glasses on, and that your enthusiasm is mostly wishful
thinking. Will there be good things about jsonb? Of course. Will
lots of people want to use it
On Tue, Feb 25, 2014 at 12:18:02PM -0500, Peter Eisentraut wrote:
On 2/25/14, 11:08 AM, Christian Kruse wrote:
Hi,
On 25/02/14 17:01, Andres Freund wrote:
And if we did, we shouldn't copy it verbatim from the Debian wiki
without attribution.
Is it actually? A quick comparison
Over in
http://www.postgresql.org/message-id/bay176-w382a9de827ebc8e602b7bbc5...@phx.gbl
there's a complaint about getting stack depth limit exceeded from a
query of the form
select count(*) from gui_die_summary where (x_coord, y_coord) in
Bruce Momjian br...@momjian.us writes:
On Tue, Feb 25, 2014 at 12:18:02PM -0500, Peter Eisentraut wrote:
As I mentioned, I would just cut those introductory parts out.
Should we link to the Debian wiki content?
-1. We generally don't link to our *own* wiki in our SGML docs, let alone
things
On 2014-02-25 13:21:46 -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Tue, Feb 25, 2014 at 12:18:02PM -0500, Peter Eisentraut wrote:
As I mentioned, I would just cut those introductory parts out.
Should we link to the Debian wiki content?
-1. We generally don't link
On Tue, Feb 25, 2014 at 12:38 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/25/2014 08:13 AM, Robert Haas wrote:
I think you've got your head stuck deeply in the sand. The json data
type works exactly like the xml data type has always worked. There
have been occasional noises about making
On Mon, Feb 24, 2014 at 9:40 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
This is a small patch to improve comments in tablecmds.c. Please find
attached a patch.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
Etsuro Fujita wrote:
This is a small patch to improve comments in tablecmds.c. Please find
attached a patch.
I find both patched and unpatched to be pretty illegible. How about
something like
/*
- * Execute ALTER TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE RENAME
+ * Execute ALTER relation
On 02/25/2014 10:31 AM, Robert Haas wrote:
And I definitely don't
agree that our documentation should push people towards stuffing
everything in a JSON blob instead of using real column definitions.
Where did you get this out of my doc patch?
--
Josh Berkus
PostgreSQL Experts Inc.
On Mon, Feb 24, 2014 at 6:16 PM, Andres Freund and...@2ndquadrant.com wrote:
I actually thought they'd be too ugly to live and we'd remove them
pre-commit.
Might be getting to be about that time, then.
- if (nrels 0 || nmsgs 0 || RelcacheInitFileInval ||
forceSyncCommit)
+
On Tue, Feb 25, 2014 at 1:45 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/25/2014 10:31 AM, Robert Haas wrote:
And I definitely don't
agree that our documentation should push people towards stuffing
everything in a JSON blob instead of using real column definitions.
Where did you
On Tue, Feb 25, 2014 at 1:44 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Etsuro Fujita wrote:
This is a small patch to improve comments in tablecmds.c. Please find
attached a patch.
I find both patched and unpatched to be pretty illegible. How about
something like
/*
- * Execute
On 02/25/2014 10:50 AM, Robert Haas wrote:
On Tue, Feb 25, 2014 at 1:45 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/25/2014 10:31 AM, Robert Haas wrote:
And I definitely don't
agree that our documentation should push people towards stuffing
everything in a JSON blob instead of using real
On 02/25/2014 09:45 AM, Bruce Momjian wrote:
It hurts our adoption substantially to confuse developers. We need to
recommend one type over the other, hence Use jsonb unless you need X.
Merlin is pushing the type of multivariable comparison where *I*
wouldn't be able to make sense of which
On 02/25/2014 10:54 AM, Josh Berkus wrote:
On 02/25/2014 10:50 AM, Robert Haas wrote:
On Tue, Feb 25, 2014 at 1:45 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/25/2014 10:31 AM, Robert Haas wrote:
And I definitely don't
agree that our documentation should push people towards stuffing
Hi,
On 2014-02-25 13:47:49 -0500, Robert Haas wrote:
On Mon, Feb 24, 2014 at 6:16 PM, Andres Freund and...@2ndquadrant.com wrote:
I actually thought they'd be too ugly to live and we'd remove them
pre-commit.
Might be getting to be about that time, then.
I want to leave them in until the
I just wasted some time puzzling over strange results from pgbench.
I eventually realized that I'd been testing against the wrong server,
because rather than -p 65432 I'd typed -P 65432, thereby invoking
the recently added --progress option. pgbench has no way to know that
that isn't what I
On 24/02/14 17:38, Robert Haas wrote:
On Thu, Feb 20, 2014 at 7:27 PM, Jeremy Harris j...@wizmail.org wrote:
Run under cachegrind, it takes about N/10 last-level cache misses,
all for the new item being introduced to the heap. The existing
code takes none at all.
Can you explain this
2014-02-25 20:49 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
I just wasted some time puzzling over strange results from pgbench.
I eventually realized that I'd been testing against the wrong server,
because rather than -p 65432 I'd typed -P 65432, thereby invoking
the recently added --progress
On Tue, Feb 25, 2014 at 2:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I just wasted some time puzzling over strange results from pgbench.
I eventually realized that I'd been testing against the wrong server,
because rather than -p 65432 I'd typed -P 65432, thereby invoking
the recently added
On Tue, Feb 25, 2014 at 1:54 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/25/2014 10:50 AM, Robert Haas wrote:
On Tue, Feb 25, 2014 at 1:45 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/25/2014 10:31 AM, Robert Haas wrote:
And I definitely don't
agree that our documentation should push
I want to create new type that is similar to varchar.
its size is variable.
I use CREATE TYPE query.
I define for that type this functions:
1-typein
2-typeoute
3-typemodify_input
4-typemodify_output
5-type_transform
I can define 1 to 4 functions in CREATE TYPE
but I can't define type_transform
On Mon, Feb 24, 2014 at 9:34 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Yeah, erroring out seems good enough. Particularly if you add a hint
saying please upgrade the extension.
In past instances where this has come up, we have actually made the
.so backward-compatible. See
Robert Haas escribió:
On Mon, Feb 24, 2014 at 9:34 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Yeah, erroring out seems good enough. Particularly if you add a hint
saying please upgrade the extension.
In past instances where this has come up, we have actually made the
.so
On Tue, Feb 25, 2014 at 6:56 AM, Sergey Burladyan eshkin...@gmail.com wrote:
It looks like I found the problem, Perl use reference count and something that
is called Mortal for memory management. As I understand it, mortal is free
after FREETMPS. Plperl call FREETMPS in
Tom Lane t...@sss.pgh.pa.us wrote:
Or we could wait to see if anybody reports this sort of behavior
in a shell that won't be out of support before 9.4 gets out the
door.
We have a field report of this happening in the sh shell in Solaris
10. Our staff has confirmed this. In Solaris 10 they
On 2/1/14, 3:22 PM, Andrew Dunstan wrote:
In the end I went with the way I had suggested, because that's what the
MSVC system does - it doesn't copy any other DLLs to the bin directory.
So doing that seemed sane for backpatching, to bring the two build
systems into sync.
If you want to
Mohsen SM mohsensoodk...@gmail.com writes:
I want to create new type that is similar to varchar.
its size is variable.
I use CREATE TYPE query.
I define for that type this functions:
1-typein
2-typeoute
3-typemodify_input
4-typemodify_output
5-type_transform
I can define 1 to 4
On Mon, Feb 24, 2014 at 10:13 AM, Christian Kruse
christ...@2ndquadrant.com wrote:
To be honest, I don't like the idea of setting up this error context
only for log_lock_wait messages. This sounds unnecessary complex to me
and I think that in the few cases where this message doesn't add a
You should be able to do this without specifically referencing the names
libpq or ecpg. Look into the Makefile, if it defines
SO_MAJOR_VERSION, then it's a library you are concerned with, and then
do the copying or moving.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Josh Berkus escribió:
(to clarify below: json refers to the current varlena datatype; JSON
refers to JSON serialized data).
FWIW the term varlena json is misleading. jsonb is also varlena, only
different. I think you need a different term to say that json uses the
text representation.
--
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 25, 2014 at 2:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
To fix this, I propose removing the -P short form and only allowing the
long --progress form. I won't argue that this feature is completely
useless, but for sure it's not something
On Tue, Feb 25, 2014 at 3:36 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
May I mark this patch as Ready for Committer by myself since
this was already marked so in last CF3 and have had no objection
or new suggestion in this CF4 for more than a month?
Sounds fair.
--
Robert
On 02/25/2014 12:12 PM, Robert Haas wrote:
I don't agree that jsonb should be preferred in all but a handful of
situations. Nor do I agree that partisanship belongs in our
documentation. Therefore, -1 for your proposal to recommend that, and
+1 for Merlin's proposal to present a comparison
I'm massively in favor of this feature. (I had started writing it about
three times myself.)
The problem I see, however, is that most extensions, by recommendation,
set module_pathname = '$libdir/pgfoo', and so relocating the control
files will still end up pointing to a not relocated library
On Tue, Feb 25, 2014 at 4:03 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/25/2014 12:12 PM, Robert Haas wrote:
I don't agree that jsonb should be preferred in all but a handful of
situations. Nor do I agree that partisanship belongs in our
documentation. Therefore, -1 for your proposal to
Bruce, Tom:
Can we change this text in the template release notes?
A dump/restore using
pg_dumpallhttp://www.postgresql.org/docs/9.3/static/app-pg-dumpall.html,
or use of
pg_upgradehttp://www.postgresql.org/docs/9.3/static/pgupgrade.html, is
required for those wishing to migrate data from any
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Or we could wait to see if anybody reports this sort of behavior
in a shell that won't be out of support before 9.4 gets out the
door.
We have a field report of this happening in the sh shell in Solaris
10. Our
Josh Berkus j...@agliodbs.com writes:
Can we change this text in the template release notes?
A dump/restore using
pg_dumpallhttp://www.postgresql.org/docs/9.3/static/app-pg-dumpall.html,
or use of
pg_upgradehttp://www.postgresql.org/docs/9.3/static/pgupgrade.html, is
required for those
On 02/25/2014 03:41 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Can we change this text in the template release notes?
A dump/restore using
pg_dumpallhttp://www.postgresql.org/docs/9.3/static/app-pg-dumpall.html,
or use of
Josh Berkus j...@agliodbs.com writes:
On 02/25/2014 03:41 PM, Tom Lane wrote:
There's a very good reason for not recommending pg_dump in this context:
it won't dump everything. Yeah, if you know what you're doing, you might
use per-database pg_dump runs plus pg_dumpall -g to catch the roles
On 02/25/2014 03:59 PM, Tom Lane wrote:
If we had a page discussing the pros and cons of different upgrade
methods, yeah, I'd be in favor of reducing the release-note text to a
pointer to that page. I don't see such a page in a quick skim of the
fine manual's table of contents though?
I owe
On Tue, Feb 25, 2014 at 09:32:55AM -0500, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 02/25/2014 08:23 AM, Haribabu Kommi wrote:
It's regarding a Todo item of Bit data type header reduction in some
cases. The header contains two parts. 1) The varlena header is
Since I committed 49c817eab78c6f0ce8c3bf46766b73d6cf3190b7 to make
pg_do_encoding_conversion not fail silently, buildfarm member magpie
has been whining:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=magpiedt=2014-02-25%2011%3A00%3A08
To wit, that if you run contrib/citext's regression
On Tue, Feb 25, 2014 at 06:41:26PM -0500, Tom Lane wrote:
I'm not sure what many limitations you think pg_dumpall has that pg_dump
doesn't.
I do think that it might be time to reword this to recommend pg_upgrade
first, though. ISTM that the current wording dates from when pg_upgrade
could
* Peter Eisentraut (pete...@gmx.net) wrote:
I'm massively in favor of this feature. (I had started writing it about
three times myself.)
Agreed.
The problem I see, however, is that most extensions, by recommendation,
set module_pathname = '$libdir/pgfoo', and so relocating the control
On 02/25/2014 04:42 PM, Bruce Momjian wrote:
On Tue, Feb 25, 2014 at 06:41:26PM -0500, Tom Lane wrote:
I'm not sure what many limitations you think pg_dumpall has that pg_dump
doesn't.
I do think that it might be time to reword this to recommend pg_upgrade
first, though. ISTM that the
Tom Lane wrote:
On the
other hand, we evidently have got precious little other buildfarm
coverage of the convert() family of functions, so maybe removing
this test altogether wouldn't be the best thing either.
We do have precious little testing on encodings and conversions, yes.
The problem
Hi Kaigai-san,
2014-02-25 13:28 GMT+09:00 Kouhei Kaigai kai...@ak.jp.nec.com:
The reason why I asked the question above is, I haven't been 100% certain
about its usage. Indeed, semifactors is applied on a limited usage, but
quite easy to reproduce by extension later (using
On 02/25/2014 08:53 PM, Alvaro Herrera wrote:
Tom Lane wrote:
On the
other hand, we evidently have got precious little other buildfarm
coverage of the convert() family of functions, so maybe removing
this test altogether wouldn't be the best thing either.
We do have precious little testing
On Tue, Feb 25, 2014 at 2:55 PM, Jeremy Harris j...@wizmail.org wrote:
On 24/02/14 17:38, Robert Haas wrote:
On Thu, Feb 20, 2014 at 7:27 PM, Jeremy Harris j...@wizmail.org wrote:
Run under cachegrind, it takes about N/10 last-level cache misses,
all for the new item being introduced to the
Hi Kaigai-san,
2014-02-23 22:24 GMT+09:00 Kohei KaiGai kai...@kaigai.gr.jp:
(1) Interface to add alternative paths in addition to built-in join paths
I found that create_custom_path is not used at all in your patch.
I revised postgresql_fdw.c to use it like this.
...
/* Create join
Hello, I tried minimal implementation to do that.
At Tue, 25 Feb 2014 19:45:56 +0900, Etsuro Fujita wrote
In addition to an issue pointed out recently by Horiguchi-san, I've
found there is another issue we have to discuss. That is, we can't
build any parameterized Append paths for an
On Tue, Feb 25, 2014 at 11:13 AM, Haribabu Kommi
kommi.harib...@gmail.comwrote:
Thanks for the information, I will apply other patches also and start
testing.
When try to run the pgbench test, by default the cache-scan plan is not
chosen because of more cost. So I increased the
Hello,
At Tue, 25 Feb 2014 16:35:55 -0500, Robert Haas wrote
On Tue, Feb 25, 2014 at 3:36 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
May I mark this patch as Ready for Committer by myself since
this was already marked so in last CF3 and have had no objection
or new
On 02/26/2014 06:21 AM, Merlin Moncure wrote:
On Tue, Feb 25, 2014 at 4:03 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/25/2014 12:12 PM, Robert Haas wrote:
I don't agree that jsonb should be preferred in all but a handful of
situations. Nor do I agree that partisanship belongs in our
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
Instead of custom node, it might be better idea to improve FDW
infrastructure
to push join. For the starters, is it possible for the custom scan node
hooks to create a ForeignScan node? In general, I think, it might be better
for the custom
On Tue, Feb 25, 2014 at 8:07 PM, Craig Ringer cr...@2ndquadrant.com wrote:
Please also highlight that any change will require a full table rewrite
with an exclusive lock, so data type choices on larger tables may be
hard to change later.
It sure looks like they're binary-coercible to me:
+
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
Yes, the part-1 patch provides a set of interface portion to interact
between the backend code and extension code. Rest of part-2 and part-3
portions are contrib modules that implements its feature on top of
custom-scan API.
Just to come back to
* Peter Geoghegan (p...@heroku.com) wrote:
On Tue, Feb 25, 2014 at 8:07 PM, Craig Ringer cr...@2ndquadrant.com wrote:
Please also highlight that any change will require a full table rewrite
with an exclusive lock, so data type choices on larger tables may be
hard to change later.
It sure
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
Instead of custom node, it might be better idea to improve FDW
infrastructure to push join. For the starters, is it possible for
the custom scan node hooks to create a ForeignScan node? In general,
I think, it might be better for the
On 02/25/2014 08:54 PM, Josh Berkus wrote:
That's called a straw man argument, Robert.
Me: We should recommend that people use jsonb unless they have a
specific reason for using json.
We could also make the opposite argument - people use json unless they
have a specific reason for using jsonb.
On Feb 25, 2014, at 1:57 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
It is not in any specs, but nevertheless all major imlementations do it and
some code depends on it.
I have no doubt that some code depends on it, but all major implementations
is too strong a statement. BSON, in
1 - 100 of 103 matches
Mail list logo
