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 f
On Sat, Jul 17, 2010 at 3:25 AM, Heikki Linnakangas
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 terrible. We need to ad
On Sun, Jul 18, 2010 at 3:14 AM, Heikki Linnakangas
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 also
>> Zontan's synchronous
On Tue, Jul 20, 2010 at 8:12 PM, Peter Eisentraut 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 doesn't
On 07/21/2010 01:52 AM, Robert Haas wrote:
On Tue, Jul 20, 2010 at 5:46 PM, Alvaro Herrera
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 it directly. Rather, the i
On Wed, Jul 21, 2010 at 02:28, Andrew Dunstan wrote:
>
>
> Robert Haas wrote:
>>
>> On Tue, Jul 20, 2010 at 3:12 PM, Peter Eisentraut wrote:
>>
>>>
>>> Well, I had looked forward to actually putting the real author into the
>>> author field.
>>>
>>
>> What if there's more than one? What if you m
On Tue, 20 Jul 2010, Robert Haas wrote:
On Tue, Jul 20, 2010 at 5:41 AM, Artur Dabrowski 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 when executing some
2010/7/21 KaiGai Kohei :
> (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 executed
2010/7/21 KaiGai Kohei :
>> 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 this patch as R
On Wed, Jul 21, 2010 at 1:07 AM, Fujii Masao wrote:
> On Tue, Jul 20, 2010 at 11:14 PM, Robert Haas 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 is based
> on the Unix-domain socket.
On Wed, Jul 21, 2010 at 6:17 AM, Abhijit Menon-Sen 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 pull t
On Wed, Jul 21, 2010 at 12:39, Robert Haas wrote:
> On Wed, Jul 21, 2010 at 6:17 AM, Abhijit Menon-Sen 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,
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. An
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 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 author (
On Wed, Jul 21, 2010 at 12:46, Abhijit Menon-Sen 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 push bra
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 wa
On Tue, Jul 20, 2010 at 10:52 PM, Amber 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,
> three versions of Po
On Wed, Jul 21, 2010 at 6:56 AM, Abhijit Menon-Sen 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 wiki and pos
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, c
(2010/07/21 19:26), Robert Haas wrote:
2010/7/21 KaiGai Kohei:
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,
On Wed, Jul 21, 2010 at 13:05, Abhijit Menon-Sen 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 cares i
On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
wrote:
> 2010/7/20 Pavel Stehule :
>> 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 string_to_array(text, text),
> and you'll introduce t
2010/7/21 Robert Haas :
> On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
> wrote:
>> 2010/7/20 Pavel Stehule :
>>> 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 string_to_array(text
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 wrote:
> 2010/7/21 Robert Haas :
>> On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
>> wrote:
>>> 2010/7/20 Pavel Stehule :
here is a new version - new these functions are not a strict and
function to_string is marked as stable.
>>>
>>>
2010/7/21 Robert Haas :
> On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule
> wrote:
>> 2010/7/21 Robert Haas :
>>> On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
>>> wrote:
2010/7/20 Pavel Stehule :
> here is a new version - new these functions are not a strict and
> function to_s
2010/7/21 Pavel Stehule :
> 2010/7/21 Robert Haas :
>> On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule
>> wrote:
>>> 2010/7/21 Robert Haas :
On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
wrote:
> 2010/7/20 Pavel Stehule :
>> here is a new version - new these functions are n
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 [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 value i
On Wed, Jul 21, 2010 at 8:14 AM, Pavel Stehule wrote:
> 2010/7/21 Pavel Stehule :
>> 2010/7/21 Robert Haas :
>>> On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule
>>> wrote:
2010/7/21 Robert Haas :
> On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
> wrote:
>> 2010/7/20 Pavel St
> 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)
http://archives.postgresql.org/message-id/aanlktilgyl3y1jkdvhx02433coq7jlm
m FormIndexDatum" comment: how can I improve it?
The idea is that we could have 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-
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 rea
On Wed, Jul 21, 2010 at 10:24 AM, 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 behavio
On Wed, Jul 21, 2010 at 5:54 AM, Robert Haas 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 take text arguments i
On Tue, 20 Jul 2010 14:34:20 -0400
Robert Haas 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 who has been
working
On Jul 21, 2010, at 9:42 AM, Robert Haas wrote:
> On Wed, Jul 21, 2010 at 10:24 AM, 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
Yeb Havinga 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 prevent him from
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 i
On Wed, Jul 21, 2010 at 11:31 AM, David Christensen wrote:
>
> On Jul 21, 2010, at 9:42 AM, Robert Haas wrote:
>
>> On Wed, Jul 21, 2010 at 10:24 AM, 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 intera
On Wed, Jul 21, 2010 at 9:39 AM, Pavel Stehule 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 bad thing was done
On 22 July 2010 01:55, Robert Haas wrote:
> On Wed, Jul 21, 2010 at 9:39 AM, Pavel Stehule
> 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 and array_to_string.
>
For what it'
2010/7/21 Robert Haas :
> On Wed, Jul 21, 2010 at 9:39 AM, Pavel Stehule
> 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 to
On Wed, Jul 21, 2010 at 10:49 AM, Jonathan Corbet 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 that you
>
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 com
On Wed, Jul 21, 2010 at 12:08 PM, Brendan Jurd wrote:
> On 22 July 2010 01:55, Robert Haas wrote:
>> On Wed, Jul 21, 2010 at 9:39 AM, Pavel Stehule
>> 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 d
On Wed, Jul 21, 2010 at 12:08 PM, Pavel Stehule 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 names) - so tex
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 beha
On Wed, Jul 21, 2010 at 4:33 AM, Markus Wanner 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,
> conditional variabl
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 s
2010/7/21 Robert Haas :
> On Wed, Jul 21, 2010 at 12:08 PM, Pavel Stehule
> 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
>
On Wed, Jul 21, 2010 at 1:48 PM, Pavel Stehule wrote:
> 2010/7/21 Robert Haas :
>> On Wed, Jul 21, 2010 at 12:08 PM, Pavel Stehule
>> 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
2010/7/21 Robert Haas :
> On Wed, Jul 21, 2010 at 1:48 PM, Pavel Stehule
> wrote:
>> 2010/7/21 Robert Haas :
>>> On Wed, Jul 21, 2010 at 12:08 PM, Pavel Stehule
>>> wrote:
>> I am thinking so we have to do decision about string_to_array and
>> array_to_string deprecation first. If these
On Wed, Jul 21, 2010 at 7:40 AM, Alexander Korotkov
wrote:
> On Wed, Jul 21, 2010 at 5:54 AM, Robert Haas 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 e
On Wed, Jul 21, 2010 at 2:25 PM, Pavel Stehule wrote:
> 2010/7/21 Robert Haas :
>> On Wed, Jul 21, 2010 at 1:48 PM, Pavel Stehule
>> wrote:
>>> 2010/7/21 Robert Haas :
On Wed, Jul 21, 2010 at 12:08 PM, Pavel Stehule
wrote:
>>> I am thinking so we have to do decision about string_
--On 1. Mai 2010 23:09:23 -0400 Robert Haas wrote:
On Wed, Apr 28, 2010 at 9:15 PM, Tom Lane 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.
This may in fact be an appropriate way to
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 writes:
> * Robert Haas [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
>> but it's certainly a big nui
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 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.
>>
>> http://wiki.postgresql.org/wiki/Committing_with_G
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
locall
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 t
On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander 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
>> local work
On Wed, Jul 21, 2010 at 21:20, Robert Haas wrote:
> On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander 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 r
On Jul 21, 2010, at 2:20 PM, Robert Haas wrote:
> On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander 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 wrote:
>
> On Jul 21, 2010, at 2:20 PM, Robert Haas wrote:
>
>> On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander wrote:
6. Finally, you must push your changes back to the server.
git push
This will push changes in all bra
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
> bui
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,
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 regressi
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 adequa
On Wed, Jul 21, 2010 at 21:37, Andrew Dunstan 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 anyon
On Jul 21, 2010, at 2:39 PM, Magnus Hagander wrote:
> On Wed, Jul 21, 2010 at 21:37, Andrew Dunstan 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
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 su
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 a
On Wed, 21 Jul 2010 15:11:41 -0400
Andrew Dunstan 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
> former with the latt
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 I've
On Wed, Jul 21, 2010 at 3:31 PM, Alvaro Herrera
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. Bare
>> > git pu
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 independent
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 preve
2010/7/21 Robert Haas :
> On Wed, Jul 21, 2010 at 2:25 PM, Pavel Stehule
> wrote:
>> 2010/7/21 Robert Haas :
>>> On Wed, Jul 21, 2010 at 1:48 PM, Pavel Stehule
>>> wrote:
2010/7/21 Robert Haas :
> On Wed, Jul 21, 2010 at 12:08 PM, Pavel Stehule
> wrote:
I am thinking so
On Wed, Jul 21, 2010 at 2:28 PM, Robert Haas 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, array_unnest(), date_to
On Wed, Jul 21, 2010 at 10:25 PM, Robert Haas 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 changing that sort o
On Wed, Jul 21, 2010 at 3:37 PM, Andrew Dunstan 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 current
> branch head
Pavel Stehule 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 numbering is m
Alvaro Herrera 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 -hackers led me to thinki
On Wed, Jul 21, 2010 at 2:53 PM, Bernd Helmle wrote:
>
>
> --On 1. Mai 2010 23:09:23 -0400 Robert Haas wrote:
>
>> On Wed, Apr 28, 2010 at 9:15 PM, Tom Lane wrote:
CREATE OR REPLACE is indeed much more complicated. In fact, for
tables, I maintain that you'll need to link with -ld
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
i
On Wed, Jul 21, 2010 at 5:03 PM, Robert Haas 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 incorporating some
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
> wrote:
> > On Wed, Jul 21, 2010 at 5:54 AM, Robert Haas wrote:
> > Same benefit can be achived by replacing char * with
> > char * and length.
> > I changed !m to m == 0
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 mag...
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 mor
On Wed, Jul 21, 2010 at 2:47 PM, Alexander Korotkov
wrote:
> On Wed, Jul 21, 2010 at 10:25 PM, Robert Haas 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 n
On Wed, Jul 21, 2010 at 2:53 PM, Markus Wanner 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 what dyna
> 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 pers
2010/5/24 KaiGai Kohei :
> (2010/05/24 22:18), Robert Haas wrote:
>> 2010/5/24 KaiGai Kohei:
>>> BTW, I guess the reason why permissions on attributes are not checked here
>>> is
>>> that we missed it at v8.4 development.
>>
>> That's a little worrying. Can you construct and post a test case
>> w
(2010/07/22 8:45), Robert Haas wrote:
> 2010/5/24 KaiGai Kohei:
>> (2010/05/24 22:18), Robert Haas wrote:
>>> 2010/5/24 KaiGai Kohei:
BTW, I guess the reason why permissions on attributes are not checked here
is
that we missed it at v8.4 development.
>>>
>>> That's a little worrying
1 - 100 of 121 matches
Mail list logo
