Le 21/07/2010 23:23, Andreas Joseph Krogh a écrit :
> [...]
> 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:
>
Hi,
I found some little mistakes in HS/SR code and document.
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 9ae022a..db78b2b 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2000,7 +2000,7 @@ SET ENABLE_SEQSCAN TO OFF;
max_standby_archive_d
On Fri, 2010-05-28 at 18:01 +0300, Peter Eisentraut wrote:
> Yes, I would like to know who is connecting to what IP address. It's
> useful if you have HA setups and you need to check which way your
> connections are going.
A few comments on this patch:
The two functions aren't perfectly symmetri
On Wed, Jul 21, 2010 at 11:11 PM, Yeb Havinga wrote:
> Kevin asked me to do a preliminary review on both synchronous replication
> patches. Relevant posts on -hackers are:
Thanks for the review!
> * patch (B) encompasses functionality of (A) and more, it also addresses
> some, if not all ideas
On Thu, Jul 22, 2010 at 11:57 AM, Robert Haas wrote:
> Should we be using is_absolute_path() here instead, as libpq does?
Yes. The attached patch does that.
>> On Wed, Jul 21, 2010 at 10:09 PM, David Christensen
>> wrote:
>> If we print the local socket when it's been explicitly set via the ho
On Jul 21, 2010, at 12:31 PM, Alvaro Herrera wrote:
> 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
On Fri, Jul 16, 2010 at 10:29 AM, Jan Urbański wrote:
> The patch adds the following features:
> * \e file.txt num -> starts a editor for the current query buffer and
> puts the cursor on the [num] line
> * \ef func num -> starts a editor for a function and puts the cursor on the
> [num] line
On Wed, Jul 21, 2010 at 10:09 PM, David Christensen wrote:
>
> On Jul 21, 2010, at 8:48 PM, Fujii Masao wrote:
>
>> On Wed, Jul 21, 2010 at 7:29 PM, Robert Haas wrote:
>>> On Wed, Jul 21, 2010 at 1:07 AM, Fujii Masao wrote:
On Tue, Jul 20, 2010 at 11:14 PM, Robert Haas
wrote:
> O
On Wed, Jul 21, 2010 at 9:48 PM, Fujii Masao wrote:
> On Wed, Jul 21, 2010 at 7:29 PM, Robert Haas wrote:
>> 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
On Wed, Jul 21, 2010 at 9:52 PM, Aidan Van Dyk wrote:
> * 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
On Jul 21, 2010, at 8:48 PM, Fujii Masao wrote:
> On Wed, Jul 21, 2010 at 7:29 PM, Robert Haas wrote:
>> 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 Un
On Wed, Jul 21, 2010 at 7:29 PM, Robert Haas wrote:
> 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
On Sat, Jul 17, 2010 at 3:59 AM, Alex Hunsaker wrote:
> Patch looks and tests good to me. Only thing that seemed to be
> missing was documentation of the new pg_dump(all) and guc params.
> Find attached a stab at this. Yeah the docs I added need work, but I
> figure if you are anything like me i
mac_man2...@yahoo.it wrote:
Since I am interested just in work_mem variations, I should prevent
each query to take advantages from revious executions of the 22
queries them selves. For example, taking cache advantages.
work_mem has nothing to do with disk caching; it controls whether larger
s
(2010/07/22 10:04), Stephen Frost wrote:
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> We can find out a similar case in CreateTrigger().
>> If I was granted TRIGGER privilege on a certain table, I can create a new
>> trigger on the table without its ownership. More commonly, it allows us
>> to
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jul 21, 2010 at 9:02 PM, Stephen Frost wrote:
> > Errr, no. If I grant you REFERENCES on my table, it means you can
> > create a FK to it from some other table.
>
> Well, in that case, we should fix the fine documentation:
>
>To cre
On Wed, Jul 21, 2010 at 9:02 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> I think the relevant case might be where ymj owns fk_tbl but not
>> pk_tbl, and has REFERENCES but not SELECT on pk_tbl.
>>
>> Come to think of it, I wonder if REFERENCES on fk_tbl ought to be
>
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> We can find out a similar case in CreateTrigger().
> If I was granted TRIGGER privilege on a certain table, I can create a new
> trigger on the table without its ownership. More commonly, it allows us
> to modify a certain property of the table without
* Robert Haas (robertmh...@gmail.com) wrote:
> I think the relevant case might be where ymj owns fk_tbl but not
> pk_tbl, and has REFERENCES but not SELECT on pk_tbl.
>
> Come to think of it, I wonder if REFERENCES on fk_tbl ought to be
> sufficient to create a foreign key. Currently, it requires
2010/7/19 KaiGai Kohei :
> The attached patch is the revised one.
>
> * It was rebased to the latest git HEAD.
> * Prototype of ExecCheckRTEPerms() was changed; it become to return
> a bool value to inform the caller its access control decision, and
> its 'ereport_on_violation' argument has gone.
On Wed, 2010-04-28 at 21:15 -0400, Tom Lane wrote:
> I still say
> that COR rather than CINE semantics would be appropriate for columns.
Viewed from a locking perspective, I would disagree.
COR semantics force a table rewrite, in certain cases. That makes it
hard to predict externally how long t
(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
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
> 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
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
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
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
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...
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
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
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 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
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
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
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
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 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
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
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
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
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
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, 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
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
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
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
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
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
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
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 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
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
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 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 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
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
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
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
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
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
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
--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
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 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
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 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 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
>
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
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
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 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, 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 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
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 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
>
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 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'
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 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
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
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
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
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 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 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 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
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-
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
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
> 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 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
* 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
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
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
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
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.
>>>
>>>
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
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
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
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
1 - 100 of 121 matches
Mail list logo
