2011/10/25 Shigeru Hanada shigeru.han...@gmail.com:
Connection management
=
The pgsql_fdw establishes a new connection when a foreign server is
accessed first for the local session. Established connection is shared
between all foreign scans in the local query, and shared
On 29.10.2011 06:40, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Fri, Oct 28, 2011 at 3:50 PM, Tom Lanet...@sss.pgh.pa.us wrote:
* Range Types
This has certainly had plenty of work done too. If it's not committable
yet, I think we should mark it Returned With Feedback for
On Sat, Oct 29, 2011 at 2:21 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Oct 29, 2011 at 5:50 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Oct 28, 2011 at 8:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
* Separating bgwriter and checkpointer
Same for this one.
Will commit by
On Fri, Oct 28, 2011 at 9:50 PM, Simon Riggs si...@2ndquadrant.com wrote:
* unite recovery.conf and postgresql.conf
This one also seems to be lacking consensus more than anything else.
What do we do about that?
I'll re-read the thread in detail to see if I can break impasse.
I've added a
On Fri, Sep 9, 2011 at 10:56 AM, Fujii Masao masao.fu...@gmail.com wrote:
In previous discussion, we've reached the consensus that we should unite
recovery.conf and postgresql.conf. The attached patch does that. The
patch is WIP, I'll have to update the document, but if you notice something,
On Sat, Oct 29, 2011 at 12:25:46AM -0700, Hitoshi Harada wrote:
I have a doubt here, on sharing connection for each server. What if
there are simultaneous scan on the same plan? Say,
- Nested Loop
- Foreign Scan to table T1 on server A
- Foreign Scan to table T2 on server A
Okay, you
On Fri, Oct 28, 2011 at 5:33 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
I'm puzzled, maybe I'm not understanding a key point here though.
I think the only thing you're missing here is that, despite
appearances some days, Postgres is not run by a single hive mind. Tom
thinks there needs
On Fri, Oct 28, 2011 at 8:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
* Non-inheritable check constraints
Greg Stark claimed this one for committing a few weeks ago, but has
not done anything visible since then. Greg?
Sorry, I had hoped to look at it during pgconfeu but found Amsterdam a
bit
Hitoshi Harada umi.tan...@gmail.com writes:
I have a doubt here, on sharing connection for each server. What if
there are simultaneous scan on the same plan? Say,
- Nested Loop
- Foreign Scan to table T1 on server A
- Foreign Scan to table T2 on server A
Okay, you are thinking about
In array_in(), I see the following code:
my_extra-element_type = ~element_type;
It seems like it was explicitly changed from InvalidOid to
~element_type. At first I thought it was a mistake, but then I thought
maybe it was to ensure that the next branch was taken even if
element_type ==
Hello, I feel at a loss what to do...
I thought that code was looking for 0xED/0xF4 in the second position,
but it's actually looking for them in the first position, which makes
vastly more sense. Whee!
Anyway, I try to describe another aspect of this code a the present.
The switch block in
On Sat, Oct 29, 2011 at 1:16 PM, horiguchi.kyot...@oss.ntt.co.jp wrote:
Hello, I feel at a loss what to do...
I thought that code was looking for 0xED/0xF4 in the second position,
but it's actually looking for them in the first position, which makes
vastly more sense. Whee!
Anyway, I try
Would it be possible to remove of the double quotes in the daterange display of
BC dates?
select '[0001-10-29 BC,2011-10-29)'::daterange;
daterange
--
[0001-10-29 BC,2011-10-29)
(1 row)
after all, it's also:
select '0001-10-29 BC'::date;
date
Jeff Davis pg...@j-davis.com writes:
In array_in(), I see the following code:
my_extra-element_type = ~element_type;
It seems like it was explicitly changed from InvalidOid to
~element_type. At first I thought it was a mistake, but then I thought
maybe it was to ensure that the next branch
Robert Haas robertmh...@gmail.com writes:
I've committed this, after a good deal of hacking on the comments,
some coding style cleanup, and one bug fix:
Ummm ... why do the incrementer functions think they need to restore the
previous value on failure? AFAICS that's a waste of code and cycles,
On Fri, Oct 28, 2011 at 9:22 PM, Bruce Momjian br...@momjian.us wrote:
OK, the attached, applied patch removes the pg_upgrade dependency on the
'postgres' database existing in the new cluster. However, vacuumdb,
used by pg_upgrade, still has this dependency:
conn =
On Sat, Oct 29, 2011 at 3:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I've committed this, after a good deal of hacking on the comments,
some coding style cleanup, and one bug fix:
Ummm ... why do the incrementer functions think they need to restore the
On Fri, Oct 28, 2011 at 06:33:39PM +0200, Dimitri Fontaine wrote:
Andrew Dunstan and...@dunslane.net writes:
Er, which distros other than debian/ubuntu?
Well, any and all derivatives I guess, to begin with.
http://distrowatch.com/dwres.php?resource=independence#debian
Based on Debian
Robert Haas robertmh...@gmail.com writes:
On Sat, Oct 29, 2011 at 3:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ummm ... why do the incrementer functions think they need to restore the
previous value on failure? AFAICS that's a waste of code and cycles,
since there is only one caller and it
On Sat, Oct 29, 2011 at 8:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Hitoshi Harada umi.tan...@gmail.com writes:
I have a doubt here, on sharing connection for each server. What if
there are simultaneous scan on the same plan? Say,
- Nested Loop
- Foreign Scan to table T1 on server A
-
Hitoshi Harada umi.tan...@gmail.com writes:
On Sat, Oct 29, 2011 at 8:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I have not looked at the code, but ISTM the way that this has to work is
that you set up a portal for each active scan. Then you can fetch a few
rows at a time from any one of them.
On Sat, 2011-10-29 at 15:13 -0400, Tom Lane wrote:
What other lookups?
I just meant anything after that point in the function would surely fail
(get_type_io_data).
array_out, and I believe a bunch of other places, use the same trick.
OK. In retrospect it is a very simple trick, but at the
Would y'all accept a patch that extended the SELECT * syntax to let
you list fields to exclude from the A_Star?
Quite regularly I'll be testing queries via psql and want to see all
the columns from a fairly wide table except maybe a giant text or xml
column. A syntax like:
SELECT *
Eric,
* Eric Ridge (eeb...@gmail.com) wrote:
It seems like such a syntax would better document the
intent of a query too, rather than leaving one wondering if big_col1
was supposed to be omitted from the target list or not.
Well, I expect most here would say that any application query should
On Sat, Oct 29, 2011 at 6:35 PM, Stephen Frost sfr...@snowman.net wrote:
Maybe the SQL spec says something about this and nobody's done the work yet?
I don't know of anything like this in the spec. Also, there would be
concern about this possibly going against spec, breaking possibly valid
I agree that this feature would be quite useful and should be included in SQL.
The exact syntax is less of an issue, but just the ability to cleanly say
select all columns except for these. I have in fact argued for the same
feature in the past.
If you want to and can implement this feature
On Sat, Oct 29, 2011 at 4:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, it might not be strictly necessary for pg_utf8_increment() and
pg_eucjp_increment(), but it's clearly necessary for the generic
incrementer function for exactly the same reason it was needed in the
old coding. I suppose
2011/10/29 Hitoshi Harada umi.tan...@gmail.com:
I have a doubt here, on sharing connection for each server. What if
there are simultaneous scan on the same plan? Say,
- Nested Loop
- Foreign Scan to table T1 on server A
- Foreign Scan to table T2 on server A
Okay, you are thinking about
2011/10/30 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
On Sat, Oct 29, 2011 at 8:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I have not looked at the code, but ISTM the way that this has to work is
that you set up a portal for each active scan. Then you can fetch a
2011/10/30 Darren Duncan dar...@darrenduncan.net:
I agree that this feature would be quite useful and should be included in
SQL. The exact syntax is less of an issue, but just the ability to cleanly
say select all columns except for these. I have in fact argued for the
same feature in the
On 10/29/2011 03:26 PM, Eric Ridge wrote:
Would y'all accept a patch that extended the SELECT * syntax to let
you list fields to exclude from the A_Star?
Quite regularly I'll be testing queries via psql and want to see all
the columns from a fairly wide table except maybe a giant text or xml
31 matches
Mail list logo
