--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 be
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
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
that
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 you hope to
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
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
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
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
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
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, from
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.
In terms
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 there are
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
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
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
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
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
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 EXECUTE'd
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 functions
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
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
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
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
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
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
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
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 marked it
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 not
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
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 patch,
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
--
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 still in
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
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 :)
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 do
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,
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.
--
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
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 have a
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 this to be
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
actually
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 istmt_seq
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 -hackers
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,
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 patch
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
* 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. We don't
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, right?
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
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 if you
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 using it
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
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
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 meant.
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 commit fest
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?
There's no
57 matches
Mail list logo
