Thanks for all your responses and my apologies for putting the question in
the wrong list.
I think OLAP is the answer for my requirements.
Regards,
Hardik
On Wed, Aug 4, 2010 at 5:40 AM, Greg Smith g...@2ndquadrant.com wrote:
Hardik Belani wrote:
For this i can create a table with number
Robert Haas wrote:
On Tue, Aug 3, 2010 at 3:05 PM, Yeb Havinga yebhavi...@gmail.com 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,
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
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
On 27/07/10 13:29, Fujii Masao wrote:
On Tue, Jul 27, 2010 at 7:39 PM, Yeb Havingayebhavi...@gmail.com 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
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
On Sun, Aug 1, 2010 at 5:08 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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 Wed, Aug 4, 2010 at 3:48 AM, Yeb Havinga yebhavi...@gmail.com 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
Robert Haas wrote:
On Wed, Aug 4, 2010 at 3:48 AM, Yeb Havinga yebhavi...@gmail.com 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
On Wed, Aug 4, 2010 at 6:41 AM, Yeb Havinga yebhavi...@gmail.com 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
Robert Haas wrote:
On Wed, Aug 4, 2010 at 6:41 AM, Yeb Havinga yebhavi...@gmail.com 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
On Mon, Aug 2, 2010 at 5:20 AM, Robert Haas robertmh...@gmail.com 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
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
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 to zero?
Tom Lane wrote:
Viktor Valy vili0...@gmail.com 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
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
On Tue, Aug 3, 2010 at 7:20 AM, Pavel Stehule pavel.steh...@gmail.com 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
On 08/04/2010 06:41 AM, Robert Haas wrote:
On Wed, Aug 4, 2010 at 6:41 AM, Yeb Havingayebhavi...@gmail.com 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
On Tue, Aug 3, 2010 at 1:50 PM, Kolb, Harald (NSN - DE/Munich)
harald.k...@nsn.com 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
--
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
filename, but note that this adds the new file to staging area. To
view all changes in
On 4 August 2010 13:22, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
On Wed, Aug 4, 2010 at 9:29 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On 04/08/10 13:32, Robert Haas wrote:
On Sun, Aug 1, 2010 at 5:08 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On 02/08/10 11:45, Fujii Masao wrote:
On Sun, Aug 1, 2010 at 3:11 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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 marko.tiikk...@cs.helsinki.fi 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
On 8/4/10 5:03 PM +0300, Dean Rasheed wrote:
On 4 August 2010 14:43, Marko Tiikkajamarko.tiikk...@cs.helsinki.fi 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
On Mon, Aug 02, 2010 at 11:34:02PM -0400, Robert Haas wrote:
On Mon, Aug 2, 2010 at 11:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 2, 2010 at 10:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, it'd still work fine for \e foo. It'll just
On Wed, Aug 4, 2010 at 10:10 AM, David Fetter da...@fetter.org 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 t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 2, 2010 at 10:49 PM, Tom Lane
Hello
updated patch attached
2010/8/4 Robert Haas robertmh...@gmail.com:
On Tue, Aug 3, 2010 at 7:20 AM, Pavel Stehule pavel.steh...@gmail.com 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
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 will
David Fetter da...@fetter.org 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
2010/8/3 Josh Berkus j...@agliodbs.com:
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'
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 30, 2010 at 9:55 PM, Robert Haas robertmh...@gmail.com 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
Andrew Dunstan and...@dunslane.net 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
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 that an action
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 t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 30, 2010 at 9:55 PM, Robert Haas robertmh...@gmail.com wrote:
The smallest value for precision which requires 2 numeric_digits is
always 2; and the required number of
Robert Haas robertmh...@gmail.com 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
On Wed, Aug 4, 2010 at 12:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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 with
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
Yeb Havinga yebhavi...@gmail.com 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
| /
Joshua D. Drake j...@commandprompt.com 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
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 bada...@gmail.com writes:
On Wed, Aug 4, 2010 at 11:04, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Aug 4, 2010 at 13:11, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
On Wed, Aug 4, 2010 at 11:04, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker bada...@gmail.com 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
Alex Hunsaker bada...@gmail.com 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
On 4 August 2010 20:25, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Aug 4, 2010 at 13:11, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
On Wed, Aug 4, 2010 at 11:04, Tom Lane t...@sss.pgh.pa.us wrote:
If we were a bit earlier in the 9.0 cycle I would suggest
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
On Wed, Aug 4, 2010 at 2:58 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Joshua D. Drake j...@commandprompt.com 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.
Robert Haas robertmh...@gmail.com writes:
On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker bada...@gmail.com 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,
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, drop
Josh Berkus j...@agliodbs.com 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
04.Ağu.2010 tarihinde 22:44 saatinde, Josh Berkus j...@agliodbs.com
ş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,
Robert Haas robertmh...@gmail.com 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
On 8/4/2010 10:26 PM, Robert Haas wrote:
On Wed, Aug 4, 2010 at 2:45 PM, Tom Lanet...@sss.pgh.pa.us 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
On Wed, Aug 4, 2010 at 13:42, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker bada...@gmail.com wrote:
I think forcing an initdb might be more trouble than this wart is worth.
+1. I would not make this change unless
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 pretty
On 4 August 2010 20:58, Josh Berkus j...@agliodbs.com 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
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Aug 04, 2010 at 09:02:43PM +0100, Thom Brown wrote:
On 4 August 2010 20:58, Josh Berkus j...@agliodbs.com 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).
On Wed, Aug 4, 2010 at 3:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
On Wed, Aug 4, 2010 at 11:04, Tom Lane t...@sss.pgh.pa.us 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
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
Michael Meskes mich...@fam-meskes.de 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
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 t...@sss.pgh.pa.us 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
Thom Brown t...@linux.com 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
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 nilson.bra...@gmail.com 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
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
could
On Wed, Aug 4, 2010 at 16:33, Thom Brown t...@linux.com 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
Merlin Moncure mmonc...@gmail.com 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
Alex Hunsaker bada...@gmail.com 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
On Wed, Aug 4, 2010 at 4:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Wed, Aug 4, 2010 at 7:07 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Aug 4, 2010 at 17:07, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com 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:
On Wed, Aug 4, 2010 at 6:19 PM, Tom Lane t...@sss.pgh.pa.us 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:
Robert Haas robertmh...@gmail.com writes:
On Wed, Aug 4, 2010 at 4:07 PM, Tom Lane t...@sss.pgh.pa.us 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,
On Wed, Aug 4, 2010 at 7:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
While chatting with Haas off-list regarding how the new array/string
functions should work (see the thread in its glory here:
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
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. That's
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
On Wed, Aug 4, 2010 at 3:35 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Aug 4, 2010 at 11:19 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Aug 4, 2010 at 7:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Aug 4, 2010 at 4:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This would be good, but I'm not sure how to do it. The main problem
again is NumericDigit alignment. Only about half
On Wed, Aug 4, 2010 at 6:43 PM, Merlin Moncure mmonc...@gmail.com 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
On Wed, Aug 4, 2010 at 8:50 PM, Greg Stark gsst...@mit.edu wrote:
On Wed, Aug 4, 2010 at 3:35 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Aug 4, 2010 at 7:43 PM, Greg Smith g...@2ndquadrant.com 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.
On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Aug 4, 2010 at 8:50 PM, Greg Stark gsst...@mit.edu wrote:
On Wed, Aug 4, 2010 at 3:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, the thing about $EDITOR is that it's a very-widely-understood
convention. This one won't be, so the argument for
Greg Stark gsst...@mit.edu writes:
On Wed, Aug 4, 2010 at 11:19 PM, Tom Lane t...@sss.pgh.pa.us 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
1 - 100 of 105 matches
Mail list logo
