2010/7/21 Itagaki Takahiro itagaki.takah...@gmail.com:
I reviewed the core changes of the patch. I don't think we need
mb_string_info() at all. Instead, we can just call pg_mbxxx() functions.
I rewrote the patch to use pg_mbstrlen_with_len() and pg_mbcharcliplen().
What do you think the
On Fri, Jul 16, 2010 at 7:43 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 16/07/10 10:40, Fujii Masao wrote:
So we should always prevent the standby from applying any WAL in pg_xlog
unless walreceiver is in progress. That is, if there is no WAL available
in the
Hi Peter,
Thanks for your feedback.
On 20/07/10 19:54, Peter Eisentraut wrote:
Attached is a patch with the revised XMLEXISTS function, complete with
grammar support and regression tests. The implemented grammar is:
XMLEXISTS ( xpath_expression PASSING BY REF xml_value [BY REF] )
Though the
On Sat, Jul 17, 2010 at 3:25 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 14/07/10 09:50, Fujii Masao wrote:
TODO
The patch have no features for performance improvement of synchronous
replication. I admit that currently the performance overhead in the
master is
On Sun, Jul 18, 2010 at 3:14 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 14/07/10 09:50, Fujii Masao wrote:
Quorum commit
-
In previous discussion about synchronous replication, some people
wanted the quorum commit feature. This feature is included in
On Tue, Jul 20, 2010 at 8:12 PM, Peter Eisentraut pete...@gmx.net wrote:
My preference would be to stick to a style where we identify the
committer using the author tag and note the patch author, reviewers,
whether the committer made changes, etc. in the commit message. A
single author field
On 07/21/2010 01:52 AM, Robert Haas wrote:
On Tue, Jul 20, 2010 at 5:46 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I guess what Robert is saying is that you don't need shmem to pass
messages around. The new LISTEN implementation was just an example.
imessages aren't supposed to use
On Wed, Jul 21, 2010 at 02:28, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
On Tue, Jul 20, 2010 at 3:12 PM, Peter Eisentraut pete...@gmx.net wrote:
Well, I had looked forward to actually putting the real author into the
author field.
What if there's more than one?
On Tue, 20 Jul 2010, Robert Haas wrote:
On Tue, Jul 20, 2010 at 5:41 AM, Artur Dabrowski a...@astec.com.pl wrote:
I have been redirected here from pg-general.
I tested full text search using GIN index and it turned out that the results
depend on operating system. Not all the rows are found
2010/7/21 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/07/20 2:13), Heikki Linnakangas wrote:
On 09/07/10 06:47, KaiGai Kohei wrote:
When leaky and non-leaky functions are chained within a WHERE clause,
it will be ordered by the cost of functions. So, we have possibility
that leaky functions are
2010/7/21 KaiGai Kohei kai...@ak.jp.nec.com:
On the other hand, if it's enough from a performance
point of view to review and mark only a few built-in functions like
index operators, maybe it's ok.
I also think it is a worthful idea to try as a proof-of-concept.
Yeah. So, should we mark
On Wed, Jul 21, 2010 at 1:07 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jul 20, 2010 at 11:14 PM, Robert Haas robertmh...@gmail.com wrote:
OK, committed.
When I specify the path of the directory for the Unix-domain socket
as the host, \conninfo doesn't mention that this connection
On Wed, Jul 21, 2010 at 6:17 AM, Abhijit Menon-Sen a...@toroid.org wrote:
At 2010-07-20 13:04:12 -0400, robertmh...@gmail.com wrote:
1. Clone the origin. Then, clone the clone n times locally. This
uses hard links, so it saves disk space. But, every time you want to
pull, you first have to
On Wed, Jul 21, 2010 at 12:39, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 21, 2010 at 6:17 AM, Abhijit Menon-Sen a...@toroid.org wrote:
At 2010-07-20 13:04:12 -0400, robertmh...@gmail.com wrote:
1. Clone the origin. Then, clone the clone n times locally. This
uses hard links, so
At 2010-07-20 13:04:12 -0400, robertmh...@gmail.com wrote:
1. Clone the origin. Then, clone the clone n times locally. This
uses hard links, so it saves disk space. But, every time you want to
pull, you first have to pull to the main clone, and then to each of
the slave clones. And same
At 2010-07-20 14:34:20 -0400, robertmh...@gmail.com wrote:
I think there is also a committer field, but that doesn't always
appear and I'm not clear on how it works.
There is always a committer field, and it is set sensibly as long as the
committer has user.name and user.email set correctly
On Wed, Jul 21, 2010 at 6:46 AM, Abhijit Menon-Sen a...@toroid.org wrote:
My preference would be to stick to a style where we identify the
committer using the author tag and note the patch author, reviewers,
whether the committer made changes, etc. in the commit message.
An aside: as a patch
On Wed, Jul 21, 2010 at 12:46, Abhijit Menon-Sen a...@toroid.org wrote:
At 2010-07-20 14:34:20 -0400, robertmh...@gmail.com wrote:
I want to make sure that I don't accidentally push the last three of
those to the authoritative server...
By default (at least with a recent git), git push will
At 2010-07-21 06:39:28 -0400, robertmh...@gmail.com wrote:
Perhaps we need to write up directions on how to do that.
I'll write them if you tell me where to put them. It's trivial.
Well, per previous discussion, we're not going to change that at this
point, or maybe ever.
Sure. I just
On Tue, Jul 20, 2010 at 10:52 PM, Amber guxiaobo1...@gmail.com wrote:
I am trying to build RPostgreSQL on Solaris 10u7 X64, but have problems
with pg_config, the configure script of RPostgreSQL checks for pg_config and
got “checking for pg_config... /usr/bin/pg_config”. In Solaris 10u7 X64,
On Wed, Jul 21, 2010 at 6:56 AM, Abhijit Menon-Sen a...@toroid.org wrote:
At 2010-07-21 06:39:28 -0400, robertmh...@gmail.com wrote:
Perhaps we need to write up directions on how to do that.
I'll write them if you tell me where to put them. It's trivial.
Post 'em here or drop them on the
At 2010-07-21 12:55:55 +0200, mag...@hagander.net wrote:
We are not changing the workflow, just the tool.
OK, but I don't see why accidental merge commits need to be considered
antisocial, and banned or rebased away. Who cares if they exist? They
don't change anything you need to do to pull,
(2010/07/21 19:26), Robert Haas wrote:
2010/7/21 KaiGai Koheikai...@ak.jp.nec.com:
On the other hand, if it's enough from a performance
point of view to review and mark only a few built-in functions like
index operators, maybe it's ok.
I also think it is a worthful idea to try as a
On Wed, Jul 21, 2010 at 13:05, Abhijit Menon-Sen a...@toroid.org wrote:
At 2010-07-21 12:55:55 +0200, mag...@hagander.net wrote:
We are not changing the workflow, just the tool.
OK, but I don't see why accidental merge commits need to be considered
antisocial, and banned or rebased away. Who
On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
2010/7/20 Pavel Stehule pavel.steh...@gmail.com:
here is a new version - new these functions are not a strict and
function to_string is marked as stable.
We have array_to_string(anyarray, text) and
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
2010/7/20 Pavel Stehule pavel.steh...@gmail.com:
here is a new version - new these functions are not a strict and
function to_string is marked as stable.
We have
At 2010-07-21 06:57:53 -0400, robertmh...@gmail.com wrote:
Post 'em here or drop them on the wiki and post a link.
1. Clone the remote repository as usual:
git clone git://git.postgresql.org/git/postgresql.git
2. Create as many local clones as you want:
git clone postgresql foobar
On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
2010/7/20 Pavel Stehule pavel.steh...@gmail.com:
here is a new version - new these
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
2010/7/20 Pavel Stehule
2010/7/21 Pavel Stehule pavel.steh...@gmail.com:
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
Hello
I am sending a actualised patch.
I understand to your criticism about line numbering. I have to agree.
With line numbering the patch is longer. I have a one significant
reason for it. There are not conformance between line numbers of
CREATE FUNCTION statement and line numbers of function's
* Fujii Masao masao.fu...@gmail.com [100721 03:49]:
The patch provides quorum parameter in postgresql.conf, which
specifies how many standby servers transaction commit will wait for
WAL records to be replicated to, before the command returns a
success indication to the client. The default
On Wed, Jul 21, 2010 at 8:14 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/7/21 Pavel Stehule pavel.steh...@gmail.com:
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2010/7/21 Robert Haas
OK, I stand corrected, although I'm not totally convinced. I still
think to_array() and to_string() are not a good choice of names. I am
not sure if we should reuse the existing names (adding a third
parameter) or pick something else, like array_concat() and
split_to_array().
It was
On Tue, Jul 20, 2010 at 09:57:06AM +0400, Zotov wrote:
SELECT d1.ID, d2.ID
FROM DocPrimary d1
JOIN DocPrimary d2 ON d2.BasedOn=d1.ID
WHERE (d1.ID=234409763) or (d2.ID=234409763)
You could try rewriting it to:
SELECT d1.ID, d2.ID
FROM DocPrimary d1
JOIN DocPrimary d2 ON
Hello Zoltán, Fujii and list,
Kevin asked me to do a preliminary review on both synchronous
replication patches. Relevant posts on -hackers are:
(A) http://archives.postgresql.org/pgsql-hackers/2010-04/msg01516.php
(B)
a faster call, but it would mean copying and
pasting a lot of code from FormIndexDatum.
2) what other areas can I comment more?
sorted_cluster-20100721.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
It's tempting to propose making .psqlrc apply only in interactive
mode, period. But that would be an incompatibility with previous
releases, and I'm not sure it's the behavior we want, either.
What is a use case for having .psqlrc be read
On Wed, Jul 21, 2010 at 10:24 AM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
It's tempting to propose making .psqlrc apply only in interactive
mode, period. But that would be an incompatibility with previous
releases, and I'm not sure it's
On Wed, Jul 21, 2010 at 5:54 AM, Robert Haas robertmh...@gmail.com wrote:
This patch still needs some work. It includes a bunch of stylistic
changes that aren't relevant to the purpose of the patch. There's no
reason that I can see to change the existing levenshtein_internal
function to
On Tue, 20 Jul 2010 14:34:20 -0400
Robert Haas robertmh...@gmail.com wrote:
I have some concerns related to the upcoming conversion to git and how
we're going to avoid having things get messy as people start using the
new repository.
Here's a few responses from the point of view of somebody
On Jul 21, 2010, at 9:42 AM, Robert Haas wrote:
On Wed, Jul 21, 2010 at 10:24 AM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
It's tempting to propose making .psqlrc apply only in interactive
mode, period. But that would be an
Yeb Havinga yebhavi...@gmail.com wrote:
Kevin asked me to do a preliminary review on both synchronous
replication patches.
Thanks for doing so.
BTW, Yeb has emailed me off-list that he has more specific notes on
both patches, but has run into high priority items on his day job
which will
Hello
I am playing with foreign tables now.
I found a few small issues now:
* fg tables are not dumped via pg_dump
* autocomplete for CREATE FOREIGN DATA WRAPPER doesn't offer HANDLER
keyword (probably it isn't your problem)
* ERROR: unrecognized objkind: 18 issue
create table omega(a int, b
On Wed, Jul 21, 2010 at 11:31 AM, David Christensen da...@endpoint.com wrote:
On Jul 21, 2010, at 9:42 AM, Robert Haas wrote:
On Wed, Jul 21, 2010 at 10:24 AM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
It's tempting to propose making
On Wed, Jul 21, 2010 at 9:39 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
It was discussed before. I would to see some symmetry in names.
That's reasonable.
The
bad thing is so great names like string_to_array and array_to_string
is used,
Yeah, those names are not too good.
and second
On 22 July 2010 01:55, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 21, 2010 at 9:39 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I am thinking so we have to do decision about string_to_array and
array_to_string deprecation first.
Well, -1 from me for deprecating string_to_array
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 9:39 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
It was discussed before. I would to see some symmetry in names.
That's reasonable.
The
bad thing is so great names like string_to_array and array_to_string
is used,
On Wed, Jul 21, 2010 at 10:49 AM, Jonathan Corbet cor...@lwn.net wrote:
1. Inability to cleanly and easily (and programatically) identify who
committed what.
No, git tracks committer information separately, and it's easily
accessible. Dig into the grungy details of git-log and you'll see
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 document is adequate for our existing
On Wed, Jul 21, 2010 at 12:08 PM, Brendan Jurd dire...@gmail.com wrote:
On 22 July 2010 01:55, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 21, 2010 at 9:39 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I am thinking so we have to do decision about string_to_array and
On Wed, Jul 21, 2010 at 12:08 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I am thinking so we have to do decision about string_to_array and
array_to_string deprecation first. If these function will be
deprecated, then we can use a similar names (and probably we should to
use a similar
On Jul 21, 2010, at 12:30 , Robert Haas wrote:
array_split() and array_join(), following Perl?
+1. Seems common in other languages such as Ruby, Python, and Java as well.
Michael Glaesemann
grzm seespotcode net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Wed, 2010-07-21 at 17:24 +0300, Peter Eisentraut wrote:
On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
It's tempting to propose making .psqlrc apply only in interactive
mode, period. But that would be an incompatibility with previous
releases, and I'm not sure it's the behavior
On Wed, Jul 21, 2010 at 4:33 AM, Markus Wanner mar...@bluegap.ch wrote:
Okay, so I just need to grok the SLRU stuff. Thanks for clarifying.
Note that I sort of /want/ to mess with shared memory. It's what I know how
to deal with. It's how threaded programs work as well. Ya know, locks,
Excerpts from Peter Eisentraut's message of mié jul 21 10:24:26 -0400 2010:
On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
It's tempting to propose making .psqlrc apply only in interactive
mode, period. But that would be an incompatibility with previous
releases, and I'm not sure
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 12:08 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I am thinking so we have to do decision about string_to_array and
array_to_string deprecation first. If these function will be
deprecated, then we can use a similar
On Wed, Jul 21, 2010 at 1:48 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 12:08 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I am thinking so we have to do decision about string_to_array and
array_to_string
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 1:48 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 12:08 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I am thinking so we have to do decision
On Wed, Jul 21, 2010 at 7:40 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
On Wed, Jul 21, 2010 at 5:54 AM, Robert Haas robertmh...@gmail.com wrote:
This patch still needs some work. It includes a bunch of stylistic
changes that aren't relevant to the purpose of the patch. There's no
On Wed, Jul 21, 2010 at 2:25 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 1:48 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 12:08 PM, Pavel
--On 1. Mai 2010 23:09:23 -0400 Robert Haas robertmh...@gmail.com wrote:
On Wed, Apr 28, 2010 at 9:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
CREATE OR REPLACE is indeed much more complicated. In fact, for
tables, I maintain that you'll need to link with -ldwim to make it
work properly.
Hi,
first of all, thanks for your feedback, I enjoy the discussion.
On 07/21/2010 07:25 PM, Robert Haas wrote:
Given what you're trying to do, it does sound like you're going to
need some kind of an algorithm for space management; but you'll be
managing space within the SLRU rather than within
Aidan Van Dyk ai...@highrise.ca writes:
* Robert Haas robertmh...@gmail.com [100720 13:04]:
3. Clone the origin once. Apply patches to multiple branches by
switching branches. Playing around with it, this is probably a
tolerable way to work when you're only going back one or two branches
On ons, 2010-07-21 at 12:22 -0400, 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
Looks good. Please consolidate this with the Committers
On Wed, Jul 21, 2010 at 21:07, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2010-07-21 at 12:22 -0400, 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.
Jonathan Corbet wrote:
3. Merge commits. I believe that we have consensus that commits
should always be done as a squash, so that the history of all of our
branches is linear. But it seems to me that someone could
accidentally push a merge commit, either because they forgot to squash
After some investigation I figured that I need to add two more checks
into the ALTER TABLE code to prevent certain types of direct changes to
typed tables (see attached patch).
But it's not clear to me whether such checks should go into the Prep
or the Exec phases. Prep seems more plausible to
On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander mag...@hagander.net wrote:
6. Finally, you must push your changes back to the server.
git push
This will push changes in all branches you've updated, but only branches
that also exist on the remote side will be pushed; thus, you can have
On Wed, Jul 21, 2010 at 21:20, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander mag...@hagander.net wrote:
6. Finally, you must push your changes back to the server.
git push
This will push changes in all branches you've updated, but only branches
On Jul 21, 2010, at 2:20 PM, Robert Haas wrote:
On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander mag...@hagander.net wrote:
6. Finally, you must push your changes back to the server.
git push
This will push changes in all branches you've updated, but only branches
that also exist on the
On Wed, Jul 21, 2010 at 3:23 PM, David Christensen da...@endpoint.com wrote:
On Jul 21, 2010, at 2:20 PM, Robert Haas wrote:
On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander mag...@hagander.net wrote:
6. Finally, you must push your changes back to the server.
git push
This will push
Excerpts from Dimitri Fontaine's message of mié jul 21 15:00:48 -0400 2010:
Well, there's also the VPATH possibility, where all your build objects
are stored out of the way of the repo. So you could checkout the branch
you're interrested in, change to the associated build directory and
build
Excerpts from Robert Haas's message of mié jul 21 15:26:47 -0400 2010:
So you're working on some back branch, and make a WIP commit so you can
switch to master to make a quick commit. Create a push on master. Bare
git push. WIP commit gets pushed upstream. Oops.
Sure, oops, but I
Excerpts from Andrew Dunstan's message of mié jul 21 15:11:41 -0400 2010:
Jonathan Corbet wrote:
That seems like a terrible idea to me - why would you destroy history?
Obviously I've missed a discussion here. But, the first time somebody
wants to use bisect to pinpoint a
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 document is
On Wed, Jul 21, 2010 at 21:37, Andrew Dunstan and...@dunslane.net wrote:
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
On Jul 21, 2010, at 2:39 PM, Magnus Hagander wrote:
On Wed, Jul 21, 2010 at 21:37, Andrew Dunstan and...@dunslane.net wrote:
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.
Excerpts from Peter Eisentraut's message of mié jul 21 15:18:58 -0400 2010:
After some investigation I figured that I need to add two more checks
into the ALTER TABLE code to prevent certain types of direct changes to
typed tables (see attached patch).
But it's not clear to me whether such
Magnus Hagander wrote:
Personally, I have a strong opinion that for everything but totally trivial
patches, the committer should create a short-lived work branch where all the
work is done, and then do a squash merge back to the main branch, which is
then pushed. This pattern is not mentioned
On Wed, 21 Jul 2010 15:11:41 -0400
Andrew Dunstan and...@dunslane.net wrote:
We have a clear idea of what should be part of the public history
contained in the authoritative repo and what should be history that is
private to the developer/tester/committer. We don't want to pollute the
Here's a status update on the git conversion, as well as a call for some help
mainly in testing.
After testing a bunch of tools, I've found that using cvs2git is by far the
best option when keeping keywords. It's the one that gives only the issues
that I posted about a couple of days ago.
So
On Wed, Jul 21, 2010 at 3:31 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié jul 21 15:26:47 -0400 2010:
So you're working on some back branch, and make a WIP commit so you can
switch to master to make a quick commit. Create a push on master.
We need to decide what email addresses committers will use on the new
git repository when they commit. Although I think we have more votes
(at least from committers) for always having author == committer,
rather than possibly setting the author tag to some other value, the
issue exists
Hi to all.
I am trying to see how PostgreSQL performance changes on the basis of
work_mem. So, I am going to execute the 22 queries of TPCH
(http://www.tpc.org/tpch/) again and again, each time for a different
value of work_mem.
Since I am interested just in work_mem variations, I should
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 2:25 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 1:48 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2010/7/21 Robert Haas robertmh...@gmail.com:
On Wed, Jul 21, 2010 at 2:28 PM, Robert Haas robertmh...@gmail.com wrote:
Yeah, I'd like some more votes, too. Aside from what I suggested
(array_join/array_split), I think my favorite is your #5.
-1 for me for any name that is of the form of:
type_operation();
we don't have bytea_encode,
On Wed, Jul 21, 2010 at 10:25 PM, Robert Haas robertmh...@gmail.com wrote:
*scratches head* Aren't you just moving the same call to a different
place?
So, where you can find this different place? :) In this patch
null-terminated strings are not used at all.
Yeah, we usually try to avoid
On Wed, Jul 21, 2010 at 3:37 PM, Andrew Dunstan and...@dunslane.net wrote:
Well, either we have a terminology problem or a statement of policy that I'm
not sure I agree with, in point 2. IMNSHO, what we need to forbid is
commits that are not fast-forward commits, i.e. that do not have the
Pavel Stehule pavel.steh...@gmail.com writes:
CREATE OR REPLACE FUNCTION public.foo()
RETURNS integer
LANGUAGE plpgsql
1 AS $function$ begin
2 return 10/0;
3 end;
$function$
This is very trivial example - for more complex functions, the correct
line
Alvaro Herrera alvhe...@commandprompt.com writes:
This does not work as cleanly as you suppose, because some build
objects are stored in the source tree. configure being one of them.
So if you switch branches, configure is rerun even in a VPATH build,
which is undesirable.
Ouch. Reading
On Wed, Jul 21, 2010 at 2:53 PM, Bernd Helmle maili...@oopsware.de wrote:
--On 1. Mai 2010 23:09:23 -0400 Robert Haas robertmh...@gmail.com wrote:
On Wed, Apr 28, 2010 at 9:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
CREATE OR REPLACE is indeed much more complicated. In fact, for
tables, I
Robert Haas wrote:
We need to decide what email addresses committers will use on the new
git repository when they commit. Although I think we have more votes
(at least from committers) for always having author == committer,
rather than possibly setting the author tag to some other value, the
On Wed, Jul 21, 2010 at 5:03 PM, Robert Haas robertmh...@gmail.com wrote:
working setup in place. But we can certainly add whatever you think
is important, or maybe some language indicating that 'git commit -a'
is just an EXAMPLE of how to create a commit...
I took a crack at this, as well as
Excerpts from Robert Haas's message of mié jul 21 14:25:47 -0400 2010:
On Wed, Jul 21, 2010 at 7:40 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
On Wed, Jul 21, 2010 at 5:54 AM, Robert Haas robertmh...@gmail.com wrote:
Same benefit can be achived by replacing char * with
char * and
Excerpts from Robert Haas's message of mié jul 21 12:54:36 -0400 2010:
My initial suggestion was to say that everyone should just be
usern...@postgresql.org; but I think that met with some resistance.
Magnus, for example, tells me that he is a committer for multiple
projects, and is
Hi.
I was googling for how to create a text-seach-config with the following
properties:
- Map unicode accentuated letters to an un-accentuated equivalent
- No stop-words
- Lowercase all words
And came over this from -general:
http://www.techienuggets.com/Comments?tx=106813
Then after some
On Wed, Jul 21, 2010 at 2:47 PM, Alexander Korotkov
aekorot...@gmail.com wrote:
On Wed, Jul 21, 2010 at 10:25 PM, Robert Haas robertmh...@gmail.com wrote:
*scratches head* Aren't you just moving the same call to a different
place?
So, where you can find this different place? :) In this
On Wed, Jul 21, 2010 at 2:53 PM, Markus Wanner mar...@bluegap.ch wrote:
Consider also the contrary situation,
where the imessages stuff is not in use (even for a short period of
time, like a few minutes). Then we'd really rather not still have
memory carved out for it.
Huh? That's exactly
My initial suggestion was to say that everyone should just be
usern...@postgresql.org; but I think that met with some resistance.
Magnus, for example, tells me that he is a committer for multiple
projects, and is mag...@hagander.net at all of them. Since that's a
domain name he owns
1 - 100 of 123 matches
Mail list logo
