Robert Haas wrote:
On Tue, Aug 3, 2010 at 3:05 PM, Yeb Havinga wrote:
Yeb Havinga wrote:
The underlying cause is the failure of the code to recognize that if
relation C inherits from both A and B, where A and B both have column x,
that A.x 'is the same as' B.x, where the 'is the same a
Thanks for the advice!
Yes, we are new to linux too :)
We have chosen Eclipse, because we have already experience with it.
However, after downloading the code from CVS, we can't build it, because of
some include commands in *tutorial / complex.c *says "*No such file or
directory*". Does anybody k
On 21/07/10 18:22, Robert Haas wrote:
At the developer meeting, I promised to do the work of documenting how
committers should use git. So here's a first version.
http://wiki.postgresql.org/wiki/Committing_with_Git
Note that while anyone is welcome to comment, I mostly care about
whether the d
On 27/07/10 13:29, Fujii Masao wrote:
On Tue, Jul 27, 2010 at 7:39 PM, Yeb Havinga wrote:
Fujii Masao wrote:
I noted the changes in XlogSend where instead of *caughtup = true/false it
now returns !MyWalSnd->sndrqst. That value is initialized to false in that
procedure and it cannot be changed t
Dear Robert,
I am just considering that there may be some logical mistakes for my rule
rewriting strategy of MERGE actions.
In my current design, if we find that an action type, say UPDATE, is
replaced by INSTEAD rules, we will remove all the actions of this type from
the MERGE command, as if th
On Sun, Aug 1, 2010 at 5:08 AM, Heikki Linnakangas
wrote:
> I'm a bit disappointed that the wiki page advises against git-new-workdir -
> that's exactly what I was planning to use. It claims there's data loss
> issues with that, does someone know the details? Is there really a risk of
> data loss
On Wed, Aug 4, 2010 at 3:48 AM, Yeb Havinga wrote:
> I just read that thread. In the beginning there is a short discussion what
> the non-astonishing behaviour of the RENAME in the case of multiple origin
> inheritance should be, which is preventing renames or any property change in
> that case. I
Robert Haas wrote:
On Wed, Aug 4, 2010 at 3:48 AM, Yeb Havinga wrote:
I just read that thread. In the beginning there is a short discussion what
the non-astonishing behaviour of the RENAME in the case of multiple origin
inheritance should be, which is preventing renames or any property chang
On Wed, Aug 4, 2010 at 6:41 AM, Yeb Havinga wrote:
>> If child inherits column A from parent1 and parent2, and it is then
>> renamed to B in parent2, what should the name be in the child after
>> the rename is completed?
>
> The column should be renamed to B in parent2, child and parent1.
Uh, rea
Robert Haas wrote:
On Wed, Aug 4, 2010 at 6:41 AM, Yeb Havinga wrote:
If child inherits column A from parent1 and parent2, and it is then
renamed to B in parent2, what should the name be in the child after
the rename is completed?
The column should be renamed to B in parent2, child a
On Mon, Aug 2, 2010 at 5:20 AM, Robert Haas wrote:
> I reviewed this code in a fair amount of detail today and ended up
> rewriting it. In general terms, it's best to avoid changing things
> that are not relevant to the central purpose of the patch. This patch
> randomly adds a whole bunch of w
Hi,
After setting up a real SR cluster based on V9 beta3 and Fuji's SR patch
synch_rep_0722.patch
and doing some simple update_and_check tests, it seems that active and
standby are not in sync.
Can this be a problem of the SR or the HSB feature ?
Or is "fsync" still not supported ?
Used configu
Now I think patch is as good as can be. :)
I'm going to prepare less-or-equal function in same manner as this patch.
With best regards,
Alexander Korotkov.
On Aug3, 2010, at 21:16 , Greg Smith wrote:
>> That was a leftover of the trimming and comment skipping logic, which my
>> patch moves to process_command.
>
> I think there's still a trimming error here--line 195 of the new patch is now
> removing the declaration of "i" just before it sets it t
Tom Lane wrote:
> Viktor Valy writes:
> > We are 2 Students from the Technical University of Vienna. At our internship
> > we would like to develop the item of the TODO list: "Allow SET CONSTRAINTS
> > to be qualified by schema/table name".
> > Is anyone working on it?
>
> Uh, it was done years a
On 8/4/10 2:39 PM +0300, Dean Rasheed wrote:
Does this sound like a useful feature? Is this a sane approach to
implementing it? If not, has anyone else given any thought as to how
it might be implemented?
I didn't look at the patch, but so far, I've identified three problems
with the existing
On 04/08/10 12:23, Boxuan Zhai wrote:
I am just considering that there may be some logical mistakes for my rule
rewriting strategy of MERGE actions.
In my current design, if we find that an action type, say UPDATE, is
replaced by INSTEAD rules, we will remove all the actions of this type from
th
On Tue, Aug 3, 2010 at 7:20 AM, Pavel Stehule wrote:
> I hope so I found and fixed last issue - the longer functions was
> showed directly - without a pager.
As a matter of style, I suggest leaving bool *edited as the last
argument to do_edit() and inserting int lineno as the second-to-last
argum
On 08/04/2010 06:41 AM, Robert Haas wrote:
On Wed, Aug 4, 2010 at 6:41 AM, Yeb Havinga wrote:
If child inherits column A from parent1 and parent2, and it is then
renamed to B in parent2, what should the name be in the child after
the rename is completed?
The column should be renamed to B in
On Tue, Aug 3, 2010 at 1:50 PM, Kolb, Harald (NSN - DE/Munich)
wrote:
> Or is "fsync" still not supported ?
Wouldn't you need to have it set to "apply" to get the behavior you want here?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql
On Wednesday 04 August 2010 14:09:51 Heikki Linnakangas wrote:
> Yep. I believe Boxuan is using git in a simplistic way, doing just "git
> diff" to create patches. For adding new files, you need to do "git add
> ", but note that this adds the new file to "staging area". To
> view all changes in
On 4 August 2010 13:22, Marko Tiikkaja wrote:
> On 8/4/10 2:39 PM +0300, Dean Rasheed wrote:
>>
>> Does this sound like a useful feature? Is this a sane approach to
>> implementing it? If not, has anyone else given any thought as to how
>> it might be implemented?
>
> I didn't look at the patch, b
On Wed, Aug 4, 2010 at 9:29 AM, Heikki Linnakangas
wrote:
> Hmm, if I understand correctly, Daniel talks about data loss when using
> "alternates", if you e.g delete a branch and run "git gc" in the parent
> repository, because the child repository referring to the parent via the
> alternate refer
On 04/08/10 13:32, Robert Haas wrote:
On Sun, Aug 1, 2010 at 5:08 AM, Heikki Linnakangas
wrote:
I'm a bit disappointed that the wiki page advises against git-new-workdir -
that's exactly what I was planning to use. It claims there's data loss
issues with that, does someone know the details? Is
On 02/08/10 11:45, Fujii Masao wrote:
On Sun, Aug 1, 2010 at 3:11 PM, Heikki Linnakangas
wrote:
I don't think any of this quorum stuff makes much sense without explicitly
registering standbys in the master.
I'm not sure if this is a good idea. This requires users to do more
manual operations
On 8/4/10 4:31 PM +0300, Dean Rasheed wrote:
1) You can't re-evaluate the UPDATE expression like an UPDATE on a
table does. Consider for example UPDATE foo SET a=a+1; If the
tuples change before we get to them, we lose data because we
simply can't re-evaluate "a+1" in
On 08/04/2010 09:29 AM, Heikki Linnakangas wrote:
All those issues can be avoided if you only run "git gc" when all the
working directories are in a clean state, with no staged but
uncommitted changes or other funny things. I can live with that gun
tied to my ankle ;-).
But to make sure
On 4 August 2010 14:43, Marko Tiikkaja wrote:
>>> 3) You can't set the RETURNING results. You suggested that
>>> RETURNING for DELETE would return the OLD value, but that seems
>>> broken because that's not necessarily what was deleted.
>>
>> Well that's what happens for a table. A
On 8/4/10 5:03 PM +0300, Dean Rasheed wrote:
On 4 August 2010 14:43, Marko Tiikkaja wrote:
I'm not sure I understand. RETURNING in DELETE on a table fetches the old
value after it was DELETEd, so it really is what the tuple was before the
DLETE, not what is seen by the snapshot. In a BEFORE D
On Mon, Aug 02, 2010 at 11:34:02PM -0400, Robert Haas wrote:
> On Mon, Aug 2, 2010 at 11:17 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Mon, Aug 2, 2010 at 10:49 PM, Tom Lane wrote:
>
> Well, it'd still work fine for \e foo. It'll just blow up for \e
> foo 3. My concern isn't really t
On Wed, Aug 4, 2010 at 10:10 AM, David Fetter wrote:
> On Mon, Aug 02, 2010 at 11:34:02PM -0400, Robert Haas wrote:
>> On Mon, Aug 2, 2010 at 11:17 PM, Tom Lane wrote:
>> > Robert Haas writes:
>> >> On Mon, Aug 2, 2010 at 10:49 PM, Tom Lane wrote:
>>
>> Well, it'd still work fine for \e foo. I
Hello
updated patch attached
2010/8/4 Robert Haas :
> On Tue, Aug 3, 2010 at 7:20 AM, Pavel Stehule wrote:
>> I hope so I found and fixed last issue - the longer functions was
>> showed directly - without a pager.
>
> As a matter of style, I suggest leaving bool *edited as the last
> argument to
On Wed, 2010-08-04 at 17:23 +0800, Boxuan Zhai wrote:
> Dear Robert,
>
> I am just considering that there may be some logical mistakes for my
> rule rewriting strategy of MERGE actions.
>
> In my current design, if we find that an action type, say UPDATE, is
> replaced by INSTEAD rules, we wil
David Fetter writes:
> On Mon, Aug 02, 2010 at 11:34:02PM -0400, Robert Haas wrote:
>> A side question is whether this should be an environment variable or
>> a psql variable.
> I'd say "yes." As with $EDITOR/PSQL_EDITOR, there should be something
> that looks for an overriding psql variable, dr
2010/8/3 Josh Berkus :
> On 8/2/10 3:42 PM, Itagaki Takahiro wrote:
>> Sorry for delayed reply. I moved to a new job,
>> and was very busy for it.
>
> Congratulations! Are you still at NTT Open Source?
No. Now I'm working at Forcia, Inc. (http://www.forcia.com/),
where Postgres' extensibility is
Robert Haas writes:
> On Fri, Jul 30, 2010 at 9:55 PM, Robert Haas wrote:
>> The smallest value for precision which requires 2 numeric_digits is
>> always 2; and the required number of numeric_digits increases by 1
>> each time the number of base-10 digits increases by DEC_DIGITS.
> And here is
Andrew Dunstan writes:
> On 08/04/2010 06:41 AM, Robert Haas wrote:
>> Uh, really? Wow. You want to follow the inheritance hierarchy in
>> both directions, both down and up? That seems like it could be
>> confusing.
> It seems more than confusing. It seems fundamentally wrong. It would
> cert
On Wed, 2010-08-04 at 15:36 +0100, Simon Riggs wrote:
> On Wed, 2010-08-04 at 17:23 +0800, Boxuan Zhai wrote:
> > Dear Robert,
> >
> > I am just considering that there may be some logical mistakes for my
> > rule rewriting strategy of MERGE actions.
> >
> > In my current design, if we find tha
On Wed, Aug 04, 2010 at 04:44:05AM +0200, Pavel Stehule wrote:
> > Yeah, I seem to have done a poor job of producing the patch based on the
> > repository I was working from. That said, it seems Pavel's working actively
> > on
> > a patch anyway, so perhaps my updating the old one isn't all that
On Wed, Aug 4, 2010 at 11:05 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 30, 2010 at 9:55 PM, Robert Haas wrote:
>>> The smallest value for precision which requires 2 numeric_digits is
>>> always 2; and the required number of numeric_digits increases by 1
>>> each time the number of
Robert Haas writes:
> *scratches head*
> One of those tests uses < and the other uses <=
> Which one is wrong?
Well, neither, since NUMERIC(0,0) is disallowed. However, it's probably
not the place of these functions to assume that, so I'd suggest treating
equality as valid.
hi all,
currently i am working on a big project for a german bookseller and
publisher. one of the requirements was correct hyphenation of ISBN-13
for about 14.400.000 books in postgresql database. so added support
for hyphenating isbn with the new 979-prefix and additionally added all
missing rang
On Wed, Aug 4, 2010 at 12:55 PM, Tom Lane wrote:
> Robert Haas writes:
>> *scratches head*
>
>> One of those tests uses < and the other uses <=
>
>> Which one is wrong?
>
> Well, neither, since NUMERIC(0,0) is disallowed. However, it's probably
> not the place of these functions to assume that,
On Wed, 2010-08-04 at 19:32 +0200, Jan Otto wrote:
> hi all,
>
> currently i am working on a big project for a german bookseller and
> publisher. one of the requirements was correct hyphenation of ISBN-13
> for about 14.400.000 books in postgresql database. so added support
> for hyphenating isbn
Tom Lane wrote:
Andrew Dunstan writes:
On 08/04/2010 06:41 AM, Robert Haas wrote:
Uh, really? Wow. You want to follow the inheritance hierarchy in
both directions, both down and up? That seems like it could be
confusing.
It seems more than confusing. It seems fundamentally wrong. It would
Marko Tiikkaja writes:
> According to the latter commit, not updating the snapshot could be
> preferable for EXPLAIN ANALYZE, but I don't see why this is. Maybe we
> should wait until we hear from Tom?
Sorry for not catching up on my email sooner. On the whole I'm in
agreement with the argume
Yeb Havinga writes:
> Tom Lane wrote:
>> I agree, this idea seems completely nuts. It is *not* reasonable for
>> an action applied to a child to change the definition of the parent.
> Also not in the case that we're talking about here?
> A.a_columnB.a_column
> | /
> v v
"Joshua D. Drake" wrote:
> On Wed, 2010-08-04 at 19:32 +0200, Jan Otto wrote:
>> patch against HEAD is attached and validated against a lot of
>> previously wrong and correct hyphenated isbn.
> Great! Thanks. We will get it on the review list.
I added it as "isbn update" to the 2010-09 Commi
> No. Now I'm working at Forcia, Inc. (http://www.forcia.com/),
> where Postgres' extensibility is used very much to develop
> innovative applications. I can continue to develop Postgres
> thanks to the company's support!
Cool!
My condolences to Koichi-san, though. I know he'll miss having you
Alex Hunsaker writes:
> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>> If we were a bit earlier in the 9.0 cycle I would suggest that this
>> confusion is a sufficient reason to drop the one-argument form of
>> string_agg. It's too late now though.
> FWIW I think we can still change it. Isn'
On Wed, Aug 4, 2010 at 13:11, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>>> If we were a bit earlier in the 9.0 cycle I would suggest that this
>>> confusion is a sufficient reason to drop the one-argument form of
>>> string_agg. It's too late now t
On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane wrote:
> The other thing that was being argued was whether rules should be
> changed to act that way too, and if not whether EXPLAIN ANALYZE should
> be fixed to make sure it emulates rule execution better. Personally
> I'd be in favor of changing rule exe
On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker wrote:
> I think forcing an initdb might be more trouble than this wart is worth.
+1. I would not make this change unless we have to force an initdb
anyway. And I really hope we don't, because I'm sort of hoping the
next 9.0 release will be rc1.
--
Alex Hunsaker writes:
> Either way, I don't have strong feelings on this other than if we dont
> fix it now when will we?
Well, we won't. If 9.0 ships with both forms of string_agg, we're stuck
with it IMO. It's not exactly a bug, so I won't cry if that's how
things go; but it is striking that
On 4 August 2010 20:25, Alex Hunsaker wrote:
> On Wed, Aug 4, 2010 at 13:11, Tom Lane wrote:
>> Alex Hunsaker writes:
>>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
If we were a bit earlier in the 9.0 cycle I would suggest that this
confusion is a sufficient reason to drop the one-
I have a couple ideas for further work on the numeric code that I want
to get feedback on.
1. Cramming it down some more. I propose that we introduce a third
format with a one-byte header: 1 bit for sign, 3 bits for dynamic
scale, and 4 bits for weight (the first of which is a sign bit). This
mi
On Wed, Aug 4, 2010 at 2:58 PM, Kevin Grittner
wrote:
> "Joshua D. Drake" wrote:
>> On Wed, 2010-08-04 at 19:32 +0200, Jan Otto wrote:
>
>>> patch against HEAD is attached and validated against a lot of
>>> previously wrong and correct hyphenated isbn.
>
>> Great! Thanks. We will get it on the re
Robert Haas writes:
> On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker wrote:
>> I think forcing an initdb might be more trouble than this wart is worth.
> +1. I would not make this change unless we have to force an initdb
> anyway. And I really hope we don't, because I'm sort of hoping the
> nex
> Well, it'd take an initdb to get rid of it. In the past we've avoided
> forcing initdb post-beta1 unless it was Really Necessary. OTOH, we seem
> to be in the mode of encouraging beta testers to test pg_upgrade, so
> maybe that concern isn't worth much at the moment.
If it's causing bugs, dro
Josh Berkus writes:
> If it's causing bugs, drop it now. If we include it in 9.0, we're stuck
> with it for years.
Well, it's causing bug reports, which is not exactly the same thing as bugs.
But yeah, I'm thinking we should get rid of it.
regards, tom lane
--
Sent via
04.Ağu.2010 tarihinde 22:44 saatinde, Josh Berkus
şunları yazdı:
I'm OK with forcing an initDB for RC1.
I think beta5 will be a better choice than RC 1 here.
--
Devrim GÜNDÜZ
PostgreSQL DBA @ Akinon/Markafoni, Red Hat Certified Engineer
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gundu
Robert Haas wrote:
> Please put "contrib/isn" in the name somewhere so that there is
> some overlap between the subject line and the CF entry.
It is now "contrib/isn isbn update".
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
On 8/4/2010 10:26 PM, Robert Haas wrote:
On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane wrote:
The other thing that was being argued was whether rules should be
changed to act that way too, and if not whether EXPLAIN ANALYZE should
be fixed to make sure it emulates rule execution better. Personally
On Wed, Aug 4, 2010 at 13:42, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker wrote:
>>> I think forcing an initdb might be more trouble than this wart is worth.
>
>> +1. I would not make this change unless we have to force an initdb
>> anyway. And I real
> Great, I was afraid people would want another beta if we forced an
> initdb. So a hearty +1 for fixing it and not doing another beta
> (pending other bugs obviously).
And, btw, there has been a lot of testing of pg_upgrade due to the
initdbs and otherwise. I think 9.0 is going to have a prett
On 4 August 2010 20:58, Josh Berkus wrote:
>
>> Great, I was afraid people would want another beta if we forced an
>> initdb. So a hearty +1 for fixing it and not doing another beta
>> (pending other bugs obviously).
>
> And, btw, there has been a lot of testing of pg_upgrade due to the
> initdbs
Robert Haas writes:
> I have a couple ideas for further work on the numeric code that I want
> to get feedback on.
> 1. Cramming it down some more. I propose that we introduce a third
> format with a one-byte header: 1 bit for sign, 3 bits for dynamic
> scale, and 4 bits for weight (the first of
Robert Haas writes:
> On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane wrote:
>> I seriously doubt that there are many applications out there that are
>> actually depending on this aspect of rule execution; if anything, there
>> are probably more that will see it as a bug.
> Changing EXPLAIN ANALYZE see
On Wed, Aug 04, 2010 at 09:02:43PM +0100, Thom Brown wrote:
> On 4 August 2010 20:58, Josh Berkus wrote:
> >
> >> Great, I was afraid people would want another beta if we forced
> >> an initdb. So a hearty +1 for fixing it and not doing another
> >> beta (pending other bugs obviously).
> >
> > An
On Wed, Aug 4, 2010 at 3:11 PM, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>>> If we were a bit earlier in the 9.0 cycle I would suggest that this
>>> confusion is a sufficient reason to drop the one-argument form of
>>> string_agg. It's too late now
The prices of large capacity Solid State Disks (SLCs of course) are still
too high to most of us.
But it´s already possible to find SSDs of small size (8 to 32 GB) today with
affordable prices and good performance (0,1ms access time and at least
150MB/s r/w transfer rate).
So, would it possible t
Michael Meskes wrote:
> I'd consider this a bug.
Could you explain why? The assertions that people consider it a bug
without explanation of *why* is confusing for me.
It sounds more like a feature of the ECPG interface that people
would really like, and which has been technically possible s
I wrote:
> Hm? I don't think that an initdb here would have any impact on whether
> we can call the next drop RC1 or not. We're talking about removing a
> single built-in entry in pg_proc --- it's one of the safest changes we
> could possibly make.
Well, I forgot that an aggregate involves more
On 4 August 2010 23:19, Tom Lane wrote:
> I wrote:
>> Hm? I don't think that an initdb here would have any impact on whether
>> we can call the next drop RC1 or not. We're talking about removing a
>> single built-in entry in pg_proc --- it's one of the safest changes we
>> could possibly make.
>
Thom Brown writes:
> I was afraid that the function would be pulled completely, but from
> looking at the patch, you're only removing the function with a
> single-parameter signature, which is quite innocuous.
Yes, of course, sorry if I confused anyone. It's the combination of
having both one- a
While chatting with Haas off-list regarding how the new array/string
functions should work (see the thread in its glory here:
http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg148865.html)
the debate morphed into the relative pros and cons about the proposed
concat() being marked stable
On Wed, Aug 4, 2010 at 5:09 PM, Nilson wrote:
> The prices of large capacity Solid State Disks (SLCs of course) are still
> too high to most of us.
>
> But it´s already possible to find SSDs of small size (8 to 32 GB) today with
> affordable prices and good performance (0,1ms access time and at le
On Wed, Aug 04, 2010 at 06:19:49PM -0400, Tom Lane wrote:
> I wrote:
> > Hm? I don't think that an initdb here would have any impact on whether
> > we can call the next drop RC1 or not. We're talking about removing a
> > single built-in entry in pg_proc --- it's one of the safest changes we
> > c
On Wed, Aug 4, 2010 at 16:33, Thom Brown wrote:
> I was afraid that the function would be pulled completely, but from
> looking at the patch, you're only removing the function with a
> single-parameter signature, which is quite innocuous. So I'm "for"
> now.
Ahh, Now I see why you were worried
Merlin Moncure writes:
> While chatting with Haas off-list regarding how the new array/string
> functions should work (see the thread in its glory here:
> http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg148865.html)
> the debate morphed into the relative pros and cons about the propos
Alex Hunsaker writes:
> I dunno about anyone else but (a, ',' order by a) just looks weird.
I suppose, but aren't you just focusing on the argument being constant?
In the more general case I don't think there's anything unnatural about
this syntax.
> Or in other words, any thoughts on:
> select
On Wed, Aug 4, 2010 at 4:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> I have a couple ideas for further work on the numeric code that I want
>> to get feedback on.
>
>> 1. Cramming it down some more. I propose that we introduce a third
>> format with a one-byte header: 1 bit for sign, 3 bits
On Wed, Aug 4, 2010 at 7:07 PM, Tom Lane wrote:
>> Or in other words, any thoughts on:
>> select string_agg(delim, expression);
>
> That looks pretty weird to me anyway, with or without use of ORDER BY.
> Nobody would think to write the delimiter first. Usually you put the
> "most important" argu
On Wed, Aug 4, 2010 at 17:07, Tom Lane wrote:
> Alex Hunsaker writes:
>> I dunno about anyone else but (a, ',' order by a) just looks weird.
>
> I suppose, but aren't you just focusing on the argument being constant?
Yes.
>> Or in other words, any thoughts on:
>> select string_agg(delim, expres
On Wed, Aug 4, 2010 at 6:19 PM, Tom Lane wrote:
> for: tgl, josh, badalex, mmoncure
> against: rhaas, thom
> Anybody else want to vote, or change their vote after seeing the patch?
If we're not regarding this as beta-forcing, I abstain.
--
Robert Haas
EnterpriseDB: http://www.ente
Robert Haas writes:
> On Wed, Aug 4, 2010 at 4:07 PM, Tom Lane wrote:
>> This would be good, but I'm not sure how to do it. The main problem
>> again is NumericDigit alignment. Only about half the time is the digit
>> array going to be aligned the way you need, so that puts a real crimp
>> in t
On Wed, Aug 4, 2010 at 7:00 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> While chatting with Haas off-list regarding how the new array/string
>> functions should work (see the thread in its glory here:
>> http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg148865.html)
>> the debate m
Nilson wrote:
1) usage of a S5D to temporarily store the WAL log files until a
deamon process copy them to the regular HD.
The WAL is rarely as much of a bottleneck as people think it is.
Because it's all sequential writes, so long as you put it onto a
dedicated disk there's minimal advantag
> And those two layers in the middle are already providing a significant
> speedup on burst workloads. Ultimately, all the burst stuff has to make
> it onto regular disks eventually though, if you can't fit the whole
> thing on SSD, and then you're back to solving the non-SSD problem
> again. Th
Josh Berkus wrote:
I haven't been able to test things like putting a "hot" table on a
specific SSD.
Putting a hot table or even better an index on them, where that relation
fits on SSD but the whole database doesn't, can work well. But it
doesn't give the speedup levels people expect beca
On Wed, Aug 4, 2010 at 3:35 PM, Tom Lane wrote:
> Well, the thing about $EDITOR is that it's a very-widely-understood
> convention. This one won't be, so the argument for making it an
> environment variable seems pretty thin.
Fwiw the +linenumber convention has been part of $EDITOR since
basical
On Wed, Aug 4, 2010 at 11:19 PM, Tom Lane wrote:
> What we are doing here, IMO, is not just changing string_agg() but
> instituting a project policy that we are not going to offer built-in
> aggregates with the same names and different numbers of arguments ---
> otherwise the problem will come rig
On Wed, Aug 4, 2010 at 7:27 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 4, 2010 at 4:07 PM, Tom Lane wrote:
>>> This would be good, but I'm not sure how to do it. The main problem
>>> again is NumericDigit alignment. Only about half the time is the digit
>>> array going to be alig
On Wed, Aug 4, 2010 at 6:43 PM, Merlin Moncure wrote:
> *) also, isn't it possible to change text cast influencing GUCs 'n'
> times per statement considering any query can call a function and any
> function can say, change datestyle? Shouldn't the related functions
> be marked 'volatile', not sta
On Wed, Aug 4, 2010 at 8:50 PM, Greg Stark wrote:
> On Wed, Aug 4, 2010 at 3:35 PM, Tom Lane wrote:
>> Well, the thing about $EDITOR is that it's a very-widely-understood
>> convention. This one won't be, so the argument for making it an
>> environment variable seems pretty thin.
>
> Fwiw the +l
On Wed, Aug 4, 2010 at 7:43 PM, Greg Smith wrote:
>> 2) usage of a S5D to store instructions to a make a checkpoint. Instead of
>> write the "dirty" pages directly to database files, postgreSQL could dump to
>> SSD the dirty pages and the instructions of how update the data files.
>> Later, a deam
On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas
wrote:
> All those issues can be avoided if you only run "git gc" when all the
> working directories are in a clean state, with no staged but uncommitted
> changes or other funny things. I can live with that gun tied to my ankle
> ;-).
Does even
Robert Haas writes:
> On Wed, Aug 4, 2010 at 8:50 PM, Greg Stark wrote:
>> On Wed, Aug 4, 2010 at 3:35 PM, Tom Lane wrote:
>>> Well, the thing about $EDITOR is that it's a very-widely-understood
>>> convention. This one won't be, so the argument for making it an
>>> environment variable seems p
Greg Stark writes:
> On Wed, Aug 4, 2010 at 11:19 PM, Tom Lane wrote:
>> What we are doing here, IMO, is not just changing string_agg() but
>> instituting a project policy that we are not going to offer built-in
>> aggregates with the same names and different numbers of arguments ---
>> otherwise
On 08/04/2010 10:08 PM, Daniel Farina wrote:
On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas
wrote:
All those issues can be avoided if you only run "git gc" when all the
working directories are in a clean state, with no staged but uncommitted
changes or other funny things. I can live with
1 - 100 of 105 matches
Mail list logo
