On Wed, Aug 18, 2010 at 08:25:45AM +0200, Michael Haggerty wrote:
> So let's take the simplest example: a branch BRANCH1 is created from
> trunk commit T1, then some time later another FILE1 from trunk commit T3
> is added to BRANCH1 in commit B4. How should this series of events be
> represented
Tom Lane wrote:
> I lack git-fu pretty completely, but I do have the CVS logs ;-).
> It looks like some of these commits that are being ascribed to the
> REL8_3_STABLE branch were actually only committed on HEAD. For
> instance my commit in contrib/xml2 on 28 Feb 2010 21:31:57 was
> only in HEAD.
Alex Hunsaker wrote:
> On Tue, Aug 17, 2010 at 13:52, Alex Hunsaker wrote:
>> How sure are we that its not the cvs2svn step that is screwing it up?
>
> urp, I jumped to a conclusion while skimming the cvs2git.options file
> Magnus posted. With all the references to svn and things like
> "GitRevi
(2010/08/18 12:02), Robert Haas wrote:
> 2010/8/17 KaiGai Kohei:
>>> I dunno. None of the above makes me feel very comfortable from a
>>> security perspective because I'm concerned any of the above could too
>>> easily be overlooked by someone upgrading. It also doesn't really
>>> address the con
2010/8/17 KaiGai Kohei :
>> I dunno. None of the above makes me feel very comfortable from a
>> security perspective because I'm concerned any of the above could too
>> easily be overlooked by someone upgrading. It also doesn't really
>> address the concern that, at some point, a child table coul
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> I believed that table inheritance is a unique feature in PostgreSQL.
It's actually not..
> Does the SQL spec really mention about whether a child table is an
> independent table object, or not?
The SQL spec does discuss 'subtables' and inhe
(2010/08/18 9:04), Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Robert Haas writes:
>>> Yeah. I'm not totally sure that is sensible for a MAC environment.
>>> Heck, it's arguably incorrect (though perhaps quite convenient) in a
>>> DAC environment.
>>
>> IIRC, the reason we di
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > Yeah. I'm not totally sure that is sensible for a MAC environment.
> > Heck, it's arguably incorrect (though perhaps quite convenient) in a
> > DAC environment.
>
> IIRC, the reason we did it was that we decided the SQL spec requir
(2010/08/18 3:07), Robert Haas wrote:
> On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost wrote:
>> No.. and I'm not sure we ever would. What we *have* done is removed
>> all permissions checking on child tables when a parent is being
>> queried..
>
> Yeah. I'm not totally sure that is sensible f
On Tue, Aug 17, 2010 at 10:53 PM, Greg Stark wrote:
> (Sorry for top posting and for any typos -- typing on my phone)
>
> In my earlier patch to do progress indicators for arbitrary SQL queries I
> had envisioned a setup similar to how we handle query cancellation. Psql
> could support a key like
On Tue, Aug 17, 2010 at 01:57:02PM -0600 I heard the voice of
Alex Hunsaker, and lo! it spake thus:
> On Tue, Aug 17, 2010 at 13:52, Alex Hunsaker wrote:
> > How sure are we that its not the cvs2svn step that is screwing it up?
>
> urp, I jumped to a conclusion while skimming the cvs2git.options
(Sorry for top posting and for any typos -- typing on my phone)
In my earlier patch to do progress indicators for arbitrary SQL queries I
had envisioned a setup similar to how we handle query cancellation. Psql
could support a key like SIGINFO which would make it request an update.
Clients like pg
Robert Haas writes:
> On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost wrote:
>> No.. and I'm not sure we ever would. What we *have* done is removed
>> all permissions checking on child tables when a parent is being
>> queried..
> Yeah. I'm not totally sure that is sensible for a MAC environmen
Hello!
We've aborted the git migration due to the issues Robert Haas found.
This means that the cvs repository is once again open for commits, and
we'll just restart the whole process wen ready.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent vi
Robert Haas writes:
> It looks to me like the commit I referenced in my original email is a
> manufactured merge commit that completely rewrites the tree while
> asserting that it doesn't do any such thing.
AFAICS, the commits in the 8.3 history *after* that point are sane;
at least there's one f
On Tue, Aug 17, 2010 at 13:52, Alex Hunsaker wrote:
> How sure are we that its not the cvs2svn step that is screwing it up?
urp, I jumped to a conclusion while skimming the cvs2git.options file
Magnus posted. With all the references to svn and things like
"GitRevisionRecorder('cvs2svn-tmp/git-bl
On Tue, Aug 17, 2010 at 13:43, Robert Haas wrote:
> On Tue, Aug 17, 2010 at 3:40 PM, Tom Lane wrote:
>> It'd be interesting to look into the cvs2git
>> source code to see exactly what causes it to add a commit message
>> like that.
>
> I vigorously agree.
How sure are we that its not the cvs2sv
On Tue, Aug 17, 2010 at 21:35, David Christensen wrote:
>
> On Aug 17, 2010, at 2:29 PM, Magnus Hagander wrote:
>
>> On Tue, Aug 17, 2010 at 21:28, Robert Haas wrote:
>>> On Tue, Aug 17, 2010 at 3:23 PM, Magnus Hagander
>>> wrote:
The tip of every branch, and every single tag, all have the
On Tue, Aug 17, 2010 at 3:40 PM, Tom Lane wrote:
> It'd be interesting to look into the cvs2git
> source code to see exactly what causes it to add a commit message
> like that.
I vigorously agree.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sen
BTW, those two "manufactured" commits seem to directly follow commits
into HEAD that added files that were later also added on the branch.
I dunno exactly how git represents that type of event, but maybe an
extra commit is needed? It'd be interesting to look into the cvs2git
source code to see exa
* Tom Lane [100817 15:30]:
> I lack git-fu pretty completely, but I do have the CVS logs ;-).
> It looks like some of these commits that are being ascribed to the
> REL8_3_STABLE branch were actually only committed on HEAD. For
> instance my commit in contrib/xml2 on 28 Feb 2010 21:31:57 was
>
On Tue, Aug 17, 2010 at 3:29 PM, Tom Lane wrote:
> I lack git-fu pretty completely, but I do have the CVS logs ;-).
> It looks like some of these commits that are being ascribed to the
> REL8_3_STABLE branch were actually only committed on HEAD. For
> instance my commit in contrib/xml2 on 28 Feb
On Aug 17, 2010, at 2:29 PM, Magnus Hagander wrote:
> On Tue, Aug 17, 2010 at 21:28, Robert Haas wrote:
>> On Tue, Aug 17, 2010 at 3:23 PM, Magnus Hagander wrote:
>>> The tip of every branch, and every single tag, all have the correct
>>> data in them, but some revisions in between seem majorly
On Tue, Aug 17, 2010 at 21:28, Robert Haas wrote:
> On Tue, Aug 17, 2010 at 3:23 PM, Magnus Hagander wrote:
>> The tip of every branch, and every single tag, all have the correct
>> data in them, but some revisions in between seem majorly confused.
>
> It seems to me that what we'll need to do he
Magnus Hagander writes:
> On Tue, Aug 17, 2010 at 21:16, Tom Lane wrote:
>> Um ... Magnus has not given any report that he's finished running
>> the conversion. What exactly are you looking at?
> That's the previous conversion. The one that we used to verify that
> things looked ok. Seems nobod
On Tue, Aug 17, 2010 at 3:23 PM, Magnus Hagander wrote:
> The tip of every branch, and every single tag, all have the correct
> data in them, but some revisions in between seem majorly confused.
It seems to me that what we'll need to do here is write a script to
look through the CVS history of ea
On Tue, Aug 17, 2010 at 2:21 PM, Tom Lane wrote:
> There are a couple of things I think should happen ASAP once the git
> repository is up, but weren't mentioned in Magnus' plans:
>
> 1. The various .cvsignore files need to be replaced by .gitignore files.
> I am not sure though whether this is a
On Tue, Aug 17, 2010 at 21:16, Tom Lane wrote:
> Robert Haas writes:
>> It appears that the git conversion of the CVS repository is seriously
>> screwed up. For example, if you look at this:
>
> Um ... Magnus has not given any report that he's finished running
> the conversion. What exactly are
Robert Haas writes:
> It appears that the git conversion of the CVS repository is seriously
> screwed up. For example, if you look at this:
Um ... Magnus has not given any report that he's finished running
the conversion. What exactly are you looking at?
> It's too bad that nobody noticed this
It appears that the git conversion of the CVS repository is seriously
screwed up. For example, if you look at this:
http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=shortlog;h=refs/tags/REL8_3_10
The first few revs look OK, but the you get to this:
2010-02-28
PostgreSQL...
--On 17. August 2010 20:08:51 +0200 Erik Rijkers wrote:
How can I 'change OID'? This error comes out of an initial initdb run.
(There are several other test-instances on this machine (several
running), but with their own $PGDATA, $PGPORT. - they can't interfere
with each other, can they?)
"Kevin Grittner" writes:
> I could post my .gitignore file if you like.
Yeah, let's see it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas writes:
> On Tue, Aug 17, 2010 at 2:24 PM, Tom Lane wrote:
>> I don't insist that the separation has to be crisp. I'm merely saying
>> that putting a large chunk of useful-only-at-execution-time code into
>> backend/parser is the Wrong Thing.
> OK, but there should be a reason for t
On tis, 2010-08-17 at 20:55 +0300, Peter Eisentraut wrote:
> On fre, 2010-08-13 at 20:20 -0400, Tom Lane wrote:
> > According to a discussion over in Fedora-land, $subject is true:
> > http://lists.fedoraproject.org/pipermail/devel/2010-August/140995.html
> >
> > I see several calls in plpython.c
On 18 August 2010 04:42, Tom Lane wrote:
> Robert Haas writes:
>> No, it doesn't. There are some policy decisions to be made here, too,
>> about what we wish to actually ignore. Personally, my preference
>> would be to arrange to ignore all and only *build products*, but not
>> things like *.re
Tom Lane wrote:
> Can we use a single file at the top level for policy (*.o, *.so,
> etc) and additional files lower down for specific exceptions
> (parser/gram.c)?
Yes.
Just as a start, done on a rather ad hoc basis, mine is attached.
If you put that at the top, current HEAD is clean, at le
2010/8/17 Tom Lane :
> =?ISO-8859-1?Q?C=E9dric_Villemain?=
> writes:
>> Here we are. A simple usecase.
>
> The reason you have an issue here is that the column is char(n) while
> the parameter is text. So the non-USING execute is equivalent to
>
> regression=# explain SELECT flag FROM foo where
Robert Haas writes:
> On Tue, Aug 17, 2010 at 2:21 PM, Tom Lane wrote:
>> 1. The various .cvsignore files need to be replaced by .gitignore files.
>> I am not sure though whether this is a trivial conversion --- does git
>> have similar default rules about ignoring .o, etc?
> No, it doesn't. Th
Tom Lane wrote:
> 1. The various .cvsignore files need to be replaced by .gitignore
> files.
I could post my .gitignore file if you like. I'm sure it can be
improved upon by others, but it gives me a clean `git status` result
when it should. Probably better than nothing as a start.
> * sr
On Tue, Aug 17, 2010 at 2:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane wrote:
>>> Rereading this, I see I didn't make my point very clearly. The reason
>>> this code doesn't belong in parser/ is that there's no prospect the
>>> parser itself would e
On Tue, Aug 17, 2010 at 2:21 PM, Tom Lane wrote:
> There are a couple of things I think should happen ASAP once the git
> repository is up, but weren't mentioned in Magnus' plans:
>
> 1. The various .cvsignore files need to be replaced by .gitignore files.
> I am not sure though whether this is a
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost wrote:
> > No.. and I'm not sure we ever would. What we *have* done is removed
> > all permissions checking on child tables when a parent is being
> > queried..
>
> Yeah. I'm not totally sure that is
Robert Haas writes:
> On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane wrote:
>> Rereading this, I see I didn't make my point very clearly. The reason
>> this code doesn't belong in parser/ is that there's no prospect the
>> parser itself would ever use it. ObjectAddress is an execution-time
>> creat
There are a couple of things I think should happen ASAP once the git
repository is up, but weren't mentioned in Magnus' plans:
1. The various .cvsignore files need to be replaced by .gitignore files.
I am not sure though whether this is a trivial conversion --- does git
have similar default rules
On Mon, Aug 16, 2010 at 11:41 PM, Hitoshi Harada wrote:
> 2010/8/17 Robert Haas :
>> On Sun, Aug 15, 2010 at 7:44 AM, Hitoshi Harada wrote:
>>> We (Marko, David Fetter and I) discussed on IRC about design of
>>> writeable CTEs. It does and will contain not only syntax but also
>>> miscellaneous s
On Tue, Aug 17, 2010 at 11:54, Robert Haas wrote:
> On Tue, Aug 17, 2010 at 11:46 AM, Alex Hunsaker wrote:
>> On Tue, Aug 17, 2010 at 09:21, Robert Haas wrote:
>>> On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker wrote:
On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote:
> /me is very so
On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane wrote:
> I wrote:
>> Maybe so, but the parser is expected to put out a representation that
>> will still be valid when the command is executed some time later.
>
> Rereading this, I see I didn't make my point very clearly. The reason
> this code doesn't
On Tue, August 17, 2010 19:13, Peter Eisentraut wrote:
> On tis, 2010-08-17 at 15:59 +0200, Erik Rijkers wrote:
>> creating template1 database in
>> /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/data/base/1
>> ... FATAL: could not
>> create unique index "pg_proc_oid_index"
>> DETA
On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost wrote:
> No.. and I'm not sure we ever would. What we *have* done is removed
> all permissions checking on child tables when a parent is being
> queried..
Yeah. I'm not totally sure that is sensible for a MAC environment.
Heck, it's arguably incor
* Alex Hunsaker (bada...@gmail.com) wrote:
> On Tue, Aug 17, 2010 at 06:31, Stephen Frost wrote:
> > * Peter Eisentraut (pete...@gmx.net) wrote:
> >> Other comments?
> >
> > Will we be able to use it for psql while keeping just one database
> > connection? I assume the answer is 'no', but it sure
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> >Stephen Frost wrote:
>
> > Let's not build the complication of dealing with inheiritance/
> > child relations into the external security system when we're in
> > the middle of trying to get rid of that distinction in core PG
> > though.
>
>Stephen Frost wrote:
> No.. and I'm not sure we ever would. What we *have* done is
> removed all permissions checking on child tables when a parent is
> being queried..
OK, that clarifies things. Thanks.
So, essentially that means that you need to set all ancestor levels
to something at le
On fre, 2010-08-13 at 20:20 -0400, Tom Lane wrote:
> According to a discussion over in Fedora-land, $subject is true:
> http://lists.fedoraproject.org/pipermail/devel/2010-August/140995.html
>
> I see several calls in plpython.c that seem to refer to PyCObject
> stuff.
> Anybody have any idea if w
On Tue, Aug 17, 2010 at 11:46 AM, Alex Hunsaker wrote:
> On Tue, Aug 17, 2010 at 09:21, Robert Haas wrote:
>> On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker wrote:
>>> On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote:
/me is very sorry master. Please beat your unworthy servant only
Magnus Hagander wrote:
> On Tue, Aug 17, 2010 at 4:34 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> It should get a bit faster if we reduce the number of branches it
> >> examines, which I assume is something we can do once we desupport 7.4
> >> and 8.0. ?We could also add a --since argument w
Tom Lane wrote:
> Robert Haas writes:
> > It should get a bit faster if we reduce the number of branches it
> > examines, which I assume is something we can do once we desupport 7.4
> > and 8.0. We could also add a --since argument which would doubtless
> > speed things up a lot, by truncating th
Robert Haas wrote:
> On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker wrote:
> > On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote:
> >> OK, try this. ?It takes about 14 seconds on my machine on my copy of
> >> Magnus's test repository. ?Output looks like this:
> >
> > 14 seconds! ?That sound much t
On Tue, Aug 17, 2010 at 06:31, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> Other comments?
>
> Will we be able to use it for psql while keeping just one database
> connection? I assume the answer is 'no', but it sure would be nice..
I think thats something that could be
=?ISO-8859-1?Q?C=E9dric_Villemain?= writes:
> Here we are. A simple usecase.
The reason you have an issue here is that the column is char(n) while
the parameter is text. So the non-USING execute is equivalent to
regression=# explain SELECT flag FROM foo where uid =
'cfcd208495d565ef66e7dff9f98
On tis, 2010-08-17 at 15:59 +0200, Erik Rijkers wrote:
> creating template1 database in
> /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/data/base/1 ...
> FATAL: could not
> create unique index "pg_proc_oid_index"
> DETAIL: Key (oid)=(2614) is duplicated.
Probably merge conflict
2010/8/17 Cédric Villemain :
> 2010/8/17 Tom Lane :
>> =?ISO-8859-1?Q?C=E9dric_Villemain?=
>> writes:
>>> 2010/8/16 Tom Lane :
=?ISO-8859-1?Q?C=E9dric_Villemain?=
writes:
> Unfortunely the current implementation of EXECUTE USING is not working
> this way.
Uh ... what
On tis, 2010-08-17 at 08:31 -0400, Stephen Frost wrote:
> Will we be able to use it for psql while keeping just one database
> connection? I assume the answer is 'no', but it sure would be nice..
How do you expect that to behave? I suppose the backend could send
NOTICE-like messages every 1% or
>Stephen Frost wrote:
> Let's not build the complication of dealing with inheiritance/
> child relations into the external security system when we're in
> the middle of trying to get rid of that distinction in core PG
> though.
I didn't realize we were trying to do that. I know we're working
2010/8/17 Tom Lane :
> =?ISO-8859-1?Q?C=E9dric_Villemain?=
> writes:
>> 2010/8/16 Tom Lane :
>>> =?ISO-8859-1?Q?C=E9dric_Villemain?=
>>> writes:
Unfortunely the current implementation of EXECUTE USING is not working
this way.
>>>
>>> Uh ... what do you base that statement on?
>
>> Abo
On Tue, Aug 17, 2010 at 09:21, Robert Haas wrote:
> On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker wrote:
>> On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote:
>>> /me is very sorry master. Please beat your unworthy servant only
>>> lightly... or alternatively, buy me a faster machine.
>>
>> W
Yeb Havinga writes:
> This message is probably in the top 10 of 2010's most insignificant
> messages, but:
> _outPlannedStmt does not write the bool field transientPlan and it is
> not accompanied by the comment /* NB: this isn't a complete set of
> fields */ that exist at other places.
[ squ
I wrote:
> Maybe so, but the parser is expected to put out a representation that
> will still be valid when the command is executed some time later.
Rereading this, I see I didn't make my point very clearly. The reason
this code doesn't belong in parser/ is that there's no prospect the
parser its
On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker wrote:
> On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote:
>> /me is very sorry master. Please beat your unworthy servant only
>> lightly... or alternatively, buy me a faster machine.
>
> Well, I might be able to afford a beer.
Done!
--
Robert
On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote:
> On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker wrote:
>> On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote:
>>> OK, try this. It takes about 14 seconds on my machine on my copy of
>>> Magnus's test repository. Output looks like this:
>>
>> 14
On Tue, Aug 17, 2010 at 4:34 PM, Tom Lane wrote:
> Robert Haas writes:
>> It should get a bit faster if we reduce the number of branches it
>> examines, which I assume is something we can do once we desupport 7.4
>> and 8.0. We could also add a --since argument which would doubtless
>> speed thi
Robert Haas writes:
> It should get a bit faster if we reduce the number of branches it
> examines, which I assume is something we can do once we desupport 7.4
> and 8.0. We could also add a --since argument which would doubtless
> speed things up a lot, by truncating the history to, say, the las
=?ISO-8859-1?Q?C=E9dric_Villemain?= writes:
> 2010/8/16 Tom Lane :
>> =?ISO-8859-1?Q?C=E9dric_Villemain?=
>> writes:
>>> Unfortunely the current implementation of EXECUTE USING is not working
>>> this way.
>>
>> Uh ... what do you base that statement on?
> About the planning behavior ?
> With
On Tue, Aug 17, 2010 at 4:17 PM, Robert Haas wrote:
> On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker wrote:
>> On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote:
>>> OK, try this. It takes about 14 seconds on my machine on my copy of
>>> Magnus's test repository. Output looks like this:
>>
>> 1
On Tue, Aug 17, 2010 at 2:58 PM, Quan Zongliang wrote:
>
> Sorry.
> I forget to attach the patch file.
Without looking at the details of this patch, it looks reasonable - so
please put it on the commitfest page, if you haven't already.
It does, however, lack documentation updates - that needs to
On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker wrote:
> On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote:
>> OK, try this. It takes about 14 seconds on my machine on my copy of
>> Magnus's test repository. Output looks like this:
>
> 14 seconds! That sound much too slow :-)
/me is very sorry
Bruce Momjian writes:
> Tom Lane wrote:
>> IOW, please no more CVS commits after 14:00 GMT tomorrow, Tuesday 8/17.
> OK, would someone please send an email to hackers at that time as a
> reminder? I might not be available then.
Here you go.
Per yesterday's discussion, access to the master PG CV
Hello!
Here's a reminder, as requested: As of now (14:00 GMT), the cvs
repository is frozen. This means that no new commits may be made to
the cvs repository anymore! It is still possible to do a cvs update or
log or such operations, but please - no more commits until we have the
git stuff up and
On Tue, August 17, 2010 07:19, Peter Eisentraut wrote:
> Here is a small prototype for a query progress indicator.
>
The patch applies to cvs HEAD (9.1devel) and compiles OK, but make check fails.
./configure
--prefix=/var/data1/pg_stuff/pg_installations/pgsql.progress_indicator
--with-pgport=65
On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote:
> OK, try this. It takes about 14 seconds on my machine on my copy of
> Magnus's test repository. Output looks like this:
14 seconds! That sound much too slow :-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
Sorry.
I forget to attach the patch file.
Begin forwarded message:
Date: Mon, 16 Aug 2010 19:49:20 +0800
From: Quan Zongliang
To: pgsql-hackers@postgresql.org
Subject: patch for pg_ctl.c to add windows service start-type
Hi, all
I modified pg_ctl.c to add a new option for Windows service sta
* Peter Eisentraut (pete...@gmx.net) wrote:
> Other comments?
Will we be able to use it for psql while keeping just one database
connection? I assume the answer is 'no', but it sure would be nice..
Perhaps psql could do something for \copy commands, anyway, but it'd be
independent.
Than
This message is probably in the top 10 of 2010's most insignificant
messages, but:
_outPlannedStmt does not write the bool field transientPlan and it is
not accompanied by the comment /* NB: this isn't a complete set of
fields */ that exist at other places.
regards,
Yeb Havinga
--
Sent
On Tue, Aug 17, 2010 at 11:50:20AM +0200, Magnus Hagander wrote:
> What about 9.0?
Will come in a few minutes. I didn't have a checked out version of the 9.0
branch handy in my development environment. Regression test is currently
running.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De,
2010/8/16 Tom Lane :
> =?ISO-8859-1?Q?C=E9dric_Villemain?=
> writes:
>> Yes, and you point out another thing. EXECUTE is a way to bypass the
>> named prepare statement, to be sure query is replanned each time.
>> Unfortunely the current implementation of EXECUTE USING is not working
>> this way.
On Tue, Aug 17, 2010 at 11:46 AM, Michael Meskes wrote:
> On Mon, Aug 16, 2010 at 02:50:35PM -0400, Tom Lane wrote:
>> Better a memory leak than broken ecpg ;-). Nobody except Michael
>> is terribly comfortable with that code, so we'd all rather wait for
>> him to review and apply the patch.
>
>
On Mon, Aug 16, 2010 at 02:50:35PM -0400, Tom Lane wrote:
> Better a memory leak than broken ecpg ;-). Nobody except Michael
> is terribly comfortable with that code, so we'd all rather wait for
> him to review and apply the patch.
This patch was small enough that I felt good about it without hav
On Tue, Aug 17, 2010 at 1:59 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> According to the decision at the developer meeting, the migration to
>> git should happen 17-20 Aug. Here's my proposed timeline. This will
>> obviously affect development work some, and since the original
>> timeline c
On 2010-08-17 6:41 AM +0300, Hitoshi Harada wrote:
2010/8/17 Robert Haas:
There are really two separate features here, and it might be worth
giving them separate names and separate designs (and separate
patches). Allowing the main query to be an insert, update, or delete
seems easier than allow
88 matches
Mail list logo
