On Mon, Aug 16, 2010 at 10:56 PM, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2010-08-14 at 02:05 -0500, Jaime Casanova wrote:
BTW, why the double quotes?
Because the name contains upper case letters?
why everything seems so obvious once someone else state it? :)
sorry to state the
On 2010-08-17 6:41 AM +0300, Hitoshi Harada wrote:
2010/8/17 Robert Haasrobertmh...@gmail.com:
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
On Tue, Aug 17, 2010 at 1:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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
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
On Tue, Aug 17, 2010 at 11:46 AM, Michael Meskes mes...@postgresql.org 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
2010/8/16 Tom Lane t...@sss.pgh.pa.us:
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com
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
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,
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
--
* 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.
Sorry.
I forget to attach the patch file.
Begin forwarded message:
Date: Mon, 16 Aug 2010 19:49:20 +0800
From: Quan Zongliang quanzongli...@gmail.com
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
On Mon, Aug 16, 2010 at 18:48, Robert Haas robertmh...@gmail.com 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
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
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
Bruce Momjian br...@momjian.us 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
On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker bada...@gmail.com wrote:
On Mon, Aug 16, 2010 at 18:48, Robert Haas robertmh...@gmail.com 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
On Tue, Aug 17, 2010 at 2:58 PM, Quan Zongliang quanzongli...@gmail.com 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
On Tue, Aug 17, 2010 at 4:17 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker bada...@gmail.com wrote:
On Mon, Aug 16, 2010 at 18:48, Robert Haas robertmh...@gmail.com wrote:
OK, try this. It takes about 14 seconds on my machine on my copy of
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com writes:
2010/8/16 Tom Lane t...@sss.pgh.pa.us:
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com
writes:
Unfortunely the current implementation of EXECUTE USING is not working
this way.
Uh ... what
Robert Haas robertmh...@gmail.com 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
On Tue, Aug 17, 2010 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Tue, Aug 17, 2010 at 08:17, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker bada...@gmail.com wrote:
On Mon, Aug 16, 2010 at 18:48, Robert Haas robertmh...@gmail.com wrote:
OK, try this. It takes about 14 seconds on my machine on my copy of
Magnus's
On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker bada...@gmail.com wrote:
On Tue, Aug 17, 2010 at 08:17, Robert Haas robertmh...@gmail.com 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
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
Yeb Havinga yebhavi...@gmail.com 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
On Tue, Aug 17, 2010 at 09:21, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker bada...@gmail.com wrote:
On Tue, Aug 17, 2010 at 08:17, Robert Haas robertmh...@gmail.com wrote:
/me is very sorry master. Please beat your unworthy servant only
lightly...
2010/8/17 Tom Lane t...@sss.pgh.pa.us:
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com
writes:
2010/8/16 Tom Lane t...@sss.pgh.pa.us:
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com
writes:
Unfortunely the current implementation of EXECUTE USING
Stephen Frost sfr...@snowman.net 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
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
2010/8/17 Cédric Villemain cedric.villemain.deb...@gmail.com:
2010/8/17 Tom Lane t...@sss.pgh.pa.us:
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com
writes:
2010/8/16 Tom Lane t...@sss.pgh.pa.us:
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com
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 with
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com 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
On Tue, Aug 17, 2010 at 06:31, Stephen Frost sfr...@snowman.net 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
Robert Haas wrote:
On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker bada...@gmail.com wrote:
On Mon, Aug 16, 2010 at 18:48, Robert Haas robertmh...@gmail.com 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
Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
Magnus Hagander wrote:
On Tue, Aug 17, 2010 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Tue, Aug 17, 2010 at 11:46 AM, Alex Hunsaker bada...@gmail.com wrote:
On Tue, Aug 17, 2010 at 09:21, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker bada...@gmail.com wrote:
On Tue, Aug 17, 2010 at 08:17, Robert Haas robertmh...@gmail.com wrote:
/me
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 we
Stephen Frost sfr...@snowman.net 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
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
Stephen Frost sfr...@snowman.net 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
* Alex Hunsaker (bada...@gmail.com) wrote:
On Tue, Aug 17, 2010 at 06:31, Stephen Frost sfr...@snowman.net 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
On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost sfr...@snowman.net 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,
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
DETAIL: Key
On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Aug 17, 2010 at 11:54, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 17, 2010 at 11:46 AM, Alex Hunsaker bada...@gmail.com wrote:
On Tue, Aug 17, 2010 at 09:21, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker bada...@gmail.com wrote:
On
On Mon, Aug 16, 2010 at 11:41 PM, Hitoshi Harada umi.tan...@gmail.com wrote:
2010/8/17 Robert Haas robertmh...@gmail.com:
On Sun, Aug 15, 2010 at 7:44 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
We (Marko, David Fetter and I) discussed on IRC about design of
writeable CTEs. It does and will
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
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane t...@sss.pgh.pa.us 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.
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost sfr...@snowman.net 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
On Tue, Aug 17, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Aug 17, 2010 at 2:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Rereading this, I see I didn't make my point very clearly. The reason
this code doesn't belong in parser/ is that
Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 17, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us 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
2010/8/17 Tom Lane t...@sss.pgh.pa.us:
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com
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
Tom Lane t...@sss.pgh.pa.us 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
On 18 August 2010 04:42, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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 that
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 17, 2010 at 2:24 PM, Tom Lane t...@sss.pgh.pa.us 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,
Kevin Grittner kevin.gritt...@wicourts.gov 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:
--On 17. August 2010 20:08:51 +0200 Erik Rijkers e...@xs4all.nl 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
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...
Robert Haas robertmh...@gmail.com 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
On Tue, Aug 17, 2010 at 21:16, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Tue, Aug 17, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Aug 17, 2010 at 3:23 PM, Magnus Hagander mag...@hagander.net 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
Magnus Hagander mag...@hagander.net writes:
On Tue, Aug 17, 2010 at 21:16, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Aug 17, 2010 at 21:28, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 17, 2010 at 3:23 PM, Magnus Hagander mag...@hagander.net 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
On Aug 17, 2010, at 2:29 PM, Magnus Hagander wrote:
On Tue, Aug 17, 2010 at 21:28, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 17, 2010 at 3:23 PM, Magnus Hagander mag...@hagander.net wrote:
The tip of every branch, and every single tag, all have the correct
data in them, but some
On Tue, Aug 17, 2010 at 3:29 PM, Tom Lane t...@sss.pgh.pa.us 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
* Tom Lane t...@sss.pgh.pa.us [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
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
On Tue, Aug 17, 2010 at 3:40 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Aug 17, 2010 at 21:35, David Christensen da...@endpoint.com wrote:
On Aug 17, 2010, at 2:29 PM, Magnus Hagander wrote:
On Tue, Aug 17, 2010 at 21:28, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 17, 2010 at 3:23 PM, Magnus Hagander mag...@hagander.net
wrote:
The tip of
On Tue, Aug 17, 2010 at 13:43, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 17, 2010 at 3:40 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Aug 17, 2010 at 13:52, Alex Hunsaker bada...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
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
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost sfr...@snowman.net 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
(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
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 bada...@gmail.com 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
On Tue, Aug 17, 2010 at 10:53 PM, Greg Stark st...@mit.edu 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
(2010/08/18 3:07), Robert Haas wrote:
On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frostsfr...@snowman.net 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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Robert Haas robertmh...@gmail.com 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
(2010/08/18 9:04), Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Robert Haasrobertmh...@gmail.com 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
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
2010/8/17 KaiGai Kohei kai...@ak.jp.nec.com:
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
(2010/08/18 12:02), Robert Haas wrote:
2010/8/17 KaiGai Koheikai...@ak.jp.nec.com:
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
Alex Hunsaker wrote:
On Tue, Aug 17, 2010 at 13:52, Alex Hunsaker bada...@gmail.com 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
87 matches
Mail list logo
