2011/10/25 Shigeru Hanada :
>
> 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 between even
> sca
On 29.10.2011 06:40, Tom Lane wrote:
Robert Haas writes:
On Fri, Oct 28, 2011 at 3:50 PM, Tom Lane 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 now.
I have been thinking about lookin
On Sat, Oct 29, 2011 at 2:21 AM, Fujii Masao wrote:
> On Sat, Oct 29, 2011 at 5:50 AM, Simon Riggs wrote:
>> On Fri, Oct 28, 2011 at 8:50 PM, Tom Lane wrote:
>>
>>> * Separating bgwriter and checkpointer
>>>
>>> Same for this one.
>>
>> Will commit by end of Monday
>
> There are plenty of source
On Fri, Oct 28, 2011 at 9:50 PM, Simon Riggs 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 new comment o
On Fri, Sep 9, 2011 at 10:56 AM, Fujii Masao 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,
> please feel free t
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
>
>
On Fri, Oct 28, 2011 at 5:33 PM, Dimitri Fontaine
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 to be a single locati
On Fri, Oct 28, 2011 at 8:50 PM, Tom Lane 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 too distractin
Hitoshi Harada 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 Foreign Join,
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 == Invali
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
On Sat, Oct 29, 2011 at 1:16 PM, 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 to describe another as
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 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 was taken e
Robert Haas 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,
since there is only
On Fri, Oct 28, 2011 at 9:22 PM, Bruce Momjian 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 = connectDatabase("postgres",
On Sat, Oct 29, 2011 at 3:35 PM, Tom Lane wrote:
> Robert Haas 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? AF
On Fri, Oct 28, 2011 at 06:33:39PM +0200, Dimitri Fontaine wrote:
> Andrew Dunstan 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 GNU/Linux:
Robert Haas writes:
> On Sat, Oct 29, 2011 at 3:35 PM, Tom Lane 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 doesn't care in the least.
> Well,
On Sat, Oct 29, 2011 at 8:13 AM, Tom Lane wrote:
> Hitoshi Harada 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
Hitoshi Harada writes:
> On Sat, Oct 29, 2011 at 8:13 AM, Tom Lane 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.
> Hmm, true. Looking back at t
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 ti
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 * EXCLUD
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 sho
On Sat, Oct 29, 2011 at 6:35 PM, Stephen Frost 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
> queries, promo
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 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 we could w
2011/10/29 Hitoshi Harada :
> 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 Foreign Jo
2011/10/30 Tom Lane :
> Hitoshi Harada writes:
>> On Sat, Oct 29, 2011 at 8:13 AM, Tom Lane 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.
>
>
2011/10/30 Darren Duncan :
> 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
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
