On Thu, Jul 10, 2008 at 05:31, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Stephen R. van den Berg" <[EMAIL PROTECTED]> writes:
>> I was wondering, if there is any real advantage to actually specify say
>> 64 for the maxrows parameter to the Execute message in the PostgreSQL
>> network protocol?
> Ther
On Monday 07 July 2008 21:56:34 Bruce Momjian wrote:
> Brendan Jurd wrote:
> > On Sun, Jul 6, 2008 at 11:44 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > > Just a personal request, but I would like a permanent URL that points
> > > to the in-progress commit page and is only changed when the comm
"Stephen R. van den Berg" <[EMAIL PROTECTED]> writes:
> I was wondering, if there is any real advantage to actually specify say
> 64 for the maxrows parameter to the Execute message in the PostgreSQL
> network protocol?
There's no benefit in it from the server's perspective, if that's what
you mea
At 2008-07-09 15:11:25 -0400, [EMAIL PROTECTED] wrote:
>
> No, actually I meant having a lone "list = lappend(list, newseq);" in
> the loop, so that ExecGrantStmt_oids is called only once.
Yes, I understand what you meant. I just phrased my agreement poorly.
Here's a more precise phrasing. ;-)
(I
Hi everyone,
This is a quick update on a promise I made early in June to suggest
requirements as well as ways to add replication hooks that would support
logical replication, as opposed to the physical replication work currently
underway based on NTT's code.
Well, June was a pretty busy month,
On Wed, Jul 09, 2008 at 04:43:27PM -0400, Aidan Van Dyk wrote:
> * David Fetter <[EMAIL PROTECTED]> [080709 14:45]:
> > On Tue, Jul 08, 2008 at 09:28:34PM -0400, Alvaro Herrera wrote:
>
> > > In fact, I fail to see the point of you providing the repo if
> > > the upstream guys are apparently not
David E. Wheeler wrote:
> On Jul 9, 2008, at 13:40, Alvaro Herrera wrote:
>> One thing that jumps at me is pgTAP usage, as Zdenek said. I
>> understand that it's neat and all that, but we can't include the
>> tests because they won't run unless one installs pgTAP which seems a
>> nonstarter. So
On Jul 9, 2008, at 13:40, Alvaro Herrera wrote:
The problem is that we're in the middle of a commitfest, so
everybody is
busy reviewing other patches (in theory at least).
Of course.
One thing that jumps at me is pgTAP usage, as Zdenek said. I
understand
that it's neat and all that, but
On Wed, Jul 09, 2008 at 03:03:48PM -0400, Ken Camann wrote:
> On Wed, Jul 9, 2008 at 3:35 AM, Martijn van Oosterhout
> <[EMAIL PROTECTED]> wrote:
>
> > Just clarifying for myself: you are mostly listing theoretical problems
> > here, not actual "I ran it and got regression failures" problems, righ
* David Fetter <[EMAIL PROTECTED]> [080709 14:45]:
> On Tue, Jul 08, 2008 at 09:28:34PM -0400, Alvaro Herrera wrote:
> > In fact, I fail to see the point of you providing the repo if the
> > upstream guys are apparently not using it ...
>
> It's *very* early days to be dismissing git entirely.
David E. Wheeler wrote:
> I guess you're all just blown away by the perfection of this patch? ;-)
The problem is that we're in the middle of a commitfest, so everybody is
busy reviewing other patches (in theory at least).
One thing that jumps at me is pgTAP usage, as Zdenek said. I understand
th
"Neil Conway" <[EMAIL PROTECTED]> writes:
> On Wed, 2008-07-09 at 14:38 -0400, Alvaro Herrera wrote:
>> But patches in progress still need comments from reviewers.
>
> Certainly, but should this be done as part of the commit fest process?
> Commenting on the future direction that an in-development
I guess you're all just blown away by the perfection of this patch? ;-)
Best,
David
On Jul 7, 2008, at 18:03, David E. Wheeler wrote:
Attached is a new version of a patch to add a CITEXT contrib module.
Changes since v2:
* Optimized citext_eq() and citext_ne() (the = and <> operators,
re
Josh Berkus <[EMAIL PROTECTED]> writes:
> Well, one thing I think we want to do by having non-committer reviewers, is
> to not involve a committer at all if the patch is going to be sent back.
> So one thing I was thinking of is:
> 1) change status to "ready for committer"
> 2) post message to
Abhijit Menon-Sen escribió:
> At 2008-07-08 09:32:44 -0400, [EMAIL PROTECTED] wrote:
> > Wouldn't it be clearer to build a list with all the sequences owned by
> > the tables in istmt.objects, and then call ExecGrantStmt_oids() a
> > single time with the big list?
>
> i.e., to hoist most of the i
On Wed, Jul 9, 2008 at 3:35 AM, Martijn van Oosterhout
<[EMAIL PROTECTED]> wrote:
> Just clarifying for myself: you are mostly listing theoretical problems
> here, not actual "I ran it and got regression failures" problems, right?
Correct. This is why most of them point out that they are not
act
At 2008-07-08 09:32:44 -0400, [EMAIL PROTECTED] wrote:
>
> > > The idea of this patch is to avoid the need to make explicit
> > > grants on sequences owned by tables. [...]
>
> I had a look at this patch and it looks good. The only thing that's
> not clear to me is whether we have agreed we want t
On Wed, 2008-07-09 at 11:50 -0700, Josh Berkus wrote:
> So one thing I was thinking of is:
>
> 1) change status to "ready for committer"
> 2) post message to -hackers detailing the review and calling for a
> committer to check the patch
> 3) a committer picks it up
Sure -- or else have we could
I was wondering, if there is any real advantage to actually specify say
64 for the maxrows parameter to the Execute message in the PostgreSQL
network protocol?
I.e.:
- Is it easier on the server, because it somehow uses less total memory when
batching the Executes with 64 rows at a time?
- Is it
Neil,
> I was tasked with reviewing this for the current commit fest, although
> so far I've just been working on grokking the rest of the GIN code. But
> if you'd like to review it instead, that's fine with me.
I have plenty of other stuff I could assign you if you're not needed on
GIN.
--
--
Neil Conway wrote:
> On Wed, 2008-07-09 at 14:38 -0400, Alvaro Herrera wrote:
> > But patches in progress still need comments from reviewers.
>
> Certainly, but should this be done as part of the commit fest process?
> Commenting on the future direction that an in-development patch ought to
> take
Neil,
> One approach would be to assign a committer to each patch, in addition
> to a reviewer (the committer and the reviewer might be the same, of
> course). Once the reviewer has signed off on the patch, the committer
> can do the final check over and commit.
Well, one thing I think we want to
On Tue, Jul 08, 2008 at 09:28:34PM -0400, Alvaro Herrera wrote:
> David Fetter wrote:
> > On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote:
> > > Here is the patches he made against CVS HEAD (as of today).
> >
> > The git repository should now match this :)
> >
> > http://git.postgres
On Wed, 2008-07-09 at 14:38 -0400, Alvaro Herrera wrote:
> But patches in progress still need comments from reviewers.
Certainly, but should this be done as part of the commit fest process?
Commenting on the future direction that an in-development patch ought to
take sounds more like a task for -h
Neil Conway wrote:
> On Wed, 2008-07-09 at 10:58 -0700, Josh Berkus wrote:
> > Have received exactly zero feedback on the question of whether I should
> > be assigning reviewers to "WIP" patches or not.
>
> I suppose it depends on what exactly "WIP" means, but I should think
> that if work is sti
On Tue, 2008-07-08 at 14:51 -0400, Tom Lane wrote:
> I'd still like to take a look.
I was tasked with reviewing this for the current commit fest, although
so far I've just been working on grokking the rest of the GIN code. But
if you'd like to review it instead, that's fine with me.
-Neil
--
On Wed, 2008-07-09 at 10:59 -0700, Josh Berkus wrote:
> This commitfest we have a number of non-committer reviewers doing
> reviewing. When they're done with their review, how do they "handoff"
> to a committer for final check and commit?
One approach would be to assign a committer to each patc
Pavan,
> I think we should. For example, one of the WIP patches is submitted by
> me. One reason I marked it WIP because I was not sure what is
> considered as WIP and what is not. The patch is ready for review, but
> of course have some open items and may need further work once I
> receive the fe
On Wed, 2008-07-09 at 10:58 -0700, Josh Berkus wrote:
> Have received exactly zero feedback on the question of whether I should
> be assigning reviewers to "WIP" patches or not.
I suppose it depends on what exactly "WIP" means, but I should think
that if work is still "in progress", the patch is
On Wed, Jul 9, 2008 at 11:28 PM, Josh Berkus <[EMAIL PROTECTED]> wrote:
> Folks,
>
> Have received exactly zero feedback on the question of whether I should be
> assigning reviewers to "WIP" patches or not.
>
I think we should. For example, one of the WIP patches is submitted by
me. One reason I m
Folks,
This commitfest we have a number of non-committer reviewers doing
reviewing. When they're done with their review, how do they "handoff"
to a committer for final check and commit?
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
Folks,
Have received exactly zero feedback on the question of whether I should
be assigning reviewers to "WIP" patches or not.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Florian,
I'd be *very* interested in how they come to that assessment. I'd have
thought that the only alternative to getpeereid/getupeercred is
password-based or certificate-based authenticated - which seem *less*
secure because a) they also rely on the client having the correct uid
or gid (to r
Tom,
Unfortunately, they almost certainly don't. I'd bet long odds that
what they expect is mysql's traditional behavior,
Nope. They're looking for Oracle, which is spec-complaint since they
wrote that spec.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Jul 7, 2008, at 12:06, David E. Wheeler wrote:
I understand it but there is parallel project which should solve
this problem completely I guess in "close" future (2-3years).
Afterward this module will be obsolete and it will takes times to
remove it from contrib. It seems to me that have
Stuart Gundry wrote:
I am setting up a postgres database on a standalone system with a randomized
text password. However, the db will contain very sensitive data and my boss
is worried about the possibility of someone being able to crack the db data
if they stole the machine. Can anyone point me
I am setting up a postgres database on a standalone system with a randomized
text password. However, the db will contain very sensitive data and my boss
is worried about the possibility of someone being able to crack the db data
if they stole the machine. Can anyone point me to information about ho
On Wed, 2008-07-09 at 12:01 +, Dean Rasheed wrote:
> > Just set client_min_messages = 'LOG';
>
> True, but you would still need to be a superuser to to set the min_durations
> and
> explain parameters.
No
> The other advantage of client_sql_trace is that you could
> debug your own functio
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> On 7/9/08, Dean Rasheed <[EMAIL PROTECTED]> wrote:
>> Do I need to worry about this?
> If this allows to see values, then yes. Otherwise no.
It definitely would open a hole that doesn't exist now, which is to
see values that are inserted into an EXECUT
I noticed that some of the entries in pg_cast are shaped in a way that CREATE
CAST wouldn't let pass. For example, the cast from cidr to varchar is
effectively defined as
CREATE CAST (cidr AS varchar) WITH FUNCTION text(inet) AS ASSIGNMENT;
but CREATE CAST wouldn't allow this because the argum
Martijn van Oosterhout napsal(a):
On Tue, Jul 08, 2008 at 09:05:11PM +0200, Zdenek Kotala wrote:
All the argument here is based on the premise that we should have
database-level collation specifications, which AFAICS is not required
nor suggested by the SQL spec.
Yeah, it is not required, but b
On 7/9/08, Dean Rasheed <[EMAIL PROTECTED]> wrote:
> Of course you can still sort of see the SQL used in functions declared
> SECURITY DEFINER, using debug_print_parse, but this would be opening
> up a much more transparent way to do it.
>
> Do I need to worry about this?
If this allows to see
Of course you can still sort of see the SQL used in functions declared
SECURITY DEFINER, using debug_print_parse, but this would be opening
up a much more transparent way to do it.
Do I need to worry about this?
Dean
> Date: Wed, 9 Jul 2008 14:22:45 +030
> Just set client_min_messages = 'LOG';
True, but you would still need to be a superuser to to set the min_durations and
explain parameters. The other advantage of client_sql_trace is that you could
debug your own functions without filling up the log file. It would work better
for
multiple users
"Tino Wildenhain" <[EMAIL PROTECTED]> writes:
> The whole stuff as I understand is to fix the behavior with applications
> creating objects without quotes and accessing them "QUOTEDUPPERCASE"?
>
> Would a small script fixing the schema by using rename not fix this for
> many applications?
Well th
On 7/9/08, ITAGAKI Takahiro <[EMAIL PROTECTED]> wrote:
> Dean Rasheed <[EMAIL PROTECTED]> wrote:
> > * client_sql_trace = on | off - settable by a normal user to allow a
> > client session to see the sql_trace output. If this parameter is on,
> > the sql_trace will be logged as NOTICE output.
>
On Wed, 2008-07-09 at 09:11 +, Dean Rasheed wrote:
> Simon, I like your proposal, and I think I can see how to code it
> fairly easily.
>
> There is one thing that it doesn't allow, however, which the debug_xxx
> parameters do, and that is for a non-superuser to trace SQL used in
> functions,
Generally, the patch looks fine. There are few issues still:
- plpgsql: the result columns _do_ create local variables.
AIUI, they should not?
- pg_dump: is the psql_assert() introduction necessary, considering it
is used only in one place?
- There should be regression test for plpgsql too,
Hi,
Peter Eisentraut wrote:
...
4. Compare the "name" data type in a case-insensitive manner. This would
probably address most problem cases. Again, you can't have objects with names
different in case only. One condition to implementing this would be that this
behavior would have be tied do
Dean Rasheed <[EMAIL PROTECTED]> wrote:
> * client_sql_trace = on | off - settable by a normal user to allow a
> client session to see the sql_trace output. If this parameter is on,
> the sql_trace will be logged as NOTICE output.
In terms of security, is it ok to show normal users SQLs used in
Simon, I like your proposal, and I think I can see how to code it
fairly easily.
There is one thing that it doesn't allow, however, which the debug_xxx
parameters do, and that is for a non-superuser to trace SQL used in
functions, from an interactive client session. For me, this is quite a
big th
Am Mittwoch, 9. Juli 2008 schrieb Ken Camann:
> In trying to port postgres to 64-bit Windows, I've encountered a
> number of issues which may (or may not) affect other compilers.
Given that PostgreSQL runs fine on other 64-bit architectures, unsubstantiated
claims about other compilers being affe
Am Mittwoch, 9. Juli 2008 schrieb Gregory Stark:
> "Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> > One disadvantage is that one could no longer have objects that have names
> > different only by case, but that is probably rare and incredibly stupid
> > and can be neglected.
>
> Certainly not if
On Wednesday 09 July 2008 00:35:07 Tom Lane wrote:
> Andreas Joseph Krogh <[EMAIL PROTECTED]> writes:
> > Right. From a user's perspective 4) sounds best. I often run into problems
> > having keywords as column-names:
>
> None of the proposals on the table will remove the need to use quotes in
>
On Tue, Jul 08, 2008 at 07:01:10PM -0400, Ken Camann wrote:
> In trying to port postgres to 64-bit Windows, I've encountered a
> number of issues which may (or may not) affect other compilers. If
> you followed the other thread, this is mostly a summary with a bit
> more details so feel free to ig
On Tue, Jul 08, 2008 at 09:05:11PM +0200, Zdenek Kotala wrote:
> >All the argument here is based on the premise that we should have
> >database-level collation specifications, which AFAICS is not required
> >nor suggested by the SQL spec.
>
> Yeah, it is not required, but by my opinion it should
56 matches
Mail list logo
