On Wed, Jul 22, 2009 at 05:35, Tom Lane wrote:
> Robert Haas writes:
>> There are a few patches that have some level of committer endorsement
>> from previous discussions, and it's not clear whether any round-robin
>> review is required. These are:
>
>> Fix memory leak in win32 security functions
2009/7/14 Jaime Casanova :
> On Thu, Mar 26, 2009 at 2:39 AM, higepon wrote:
>> Here is a patch for pg_dump "Commenting on a composite-type column".
>> This patch is for Todo item named "Add dumping of comments on index
>> columns and composite type columns".
>
> this one looks good to me, the only
Robert Haas writes:
> There are a few patches that have some level of committer endorsement
> from previous discussions, and it's not clear whether any round-robin
> review is required. These are:
> Fix memory leak in win32 security functions (Magnus)
> do_tup_output_datum v2 (Tom)
> These migh
Paul Sheer wrote:
> Hadoop backend for PostGreSQL
Resurrecting an old thread, it seems some guys at Yale implemented
something very similar to what this thread was discussing.
http://dbmsmusings.blogspot.com/2009/07/announcing-release-of-hadoopdb-longer.html
> >
> >It's an open source stack t
A brief update on our progress so far. We started with 71 patches of
which 12 have been committed, 9 returned with feedback, 2 rejected,
and 1 bumped to the next CommitFest. In other words, we've closed out
just over a third of the total number of patches in the first week,
which is great progres
On Tue, Jul 21, 2009 at 10:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 21, 2009 at 7:47 PM, Tom Lane wrote:
>>> Also, I'd suggest changing the ExplainStmt struct to have a list of
>>> DefElem options instead of hard-wiring the option set at that level.
>
>> What is the advantage of
Robert Haas writes:
> On Tue, Jul 21, 2009 at 7:47 PM, Tom Lane wrote:
>> Also, I'd suggest changing the ExplainStmt struct to have a list of
>> DefElem options instead of hard-wiring the option set at that level.
> What is the advantage of that?
Fewer places to change when you add a new option;
"Kevin Grittner" writes:
> It seems like it might be reasonable to have a separate threshold for
> compression from that for out-of-line storage. Since I've been in
> that code recently, I would be pretty comfortable doing something
> about that; but, as is so often the case, the problem will pro
Tom Lane wrote:
> For the record, I think this patch is a waste of manpower and we should
> rely on dtrace/systemtap. However, if we are going to make our own
> homegrown substitute for those facilities, a minimum requirement should
> be that it uses the dtrace macros already put into the sourc
"Kevin Grittner" writes:
> I wrote:
>> Proposed patch attached.
> That first version was of the "minimally invasive" variety, to stress
> how little I was changing and minimize the chance that I would make
> some dumb error; however, it involved copy/paste of a few lines which
> were already in
On Tue, Jul 21, 2009 at 7:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> Here is an updated version of my "generic options for explain" patch.
>
> What is the rationale for essentially duplicating defGetBoolean()?
I just didn't realize we already had something along those lines.
Updated patch at
Andrew Gierth wrote:
The code already has users who are using it for audit-trail stuff
(easily computing the changes between old and new records and storing
only the differences). Perhaps one of the existing users could express
an opinion on this point.
I use it for exactly that purpose (a
"Dickson S. Guedes" wrote:
> Hum, for key names ok, but for values, wouldn't this worse the output when
> it is greater than 512 bytes?
Why do we need to cut values in 512 bytes? It might be generate larger logs
before, but we don't have any limits for length of log messages.
ex) ERROR: ...
On Tue, Jul 21, 2009 at 7:25 PM, Tom Lane wrote:
> Or maybe we should think about having two versions of hstore. This
> is all tied up in the problem of having a decent module infrastructure
> (which I hope somebody is working on for 8.5).
A decent module infrastructure is probably not going to f
* Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
> Running ALTER TABLE foo ALTER COLUMN bar TYPE hstore USING bar || '';
> on all of your hstore columns would suffice to ensure that, I believe.
> (Subject to testing once I actually have code for it, of course.)
This could/would be included in
> "Jeff" == Jeff Davis writes:
>> I'm prepared to give slightly more consideration to option #3:
>> make the new code read the old format as well as the new one. I
>> believe (though I have not yet tested) that it is possible to
>> reliably distinguish the two with relatively low overhead
> "Tom" == Tom Lane writes:
>> (b) many of the old names are significant collision risks.
Tom> What collision risks? PG does not allow loadable libraries to
Tom> export their symbols, so I don't see the problem. I recommend
Tom> just keeping those things named as they were.
You've nev
Teodor Sigaev writes:
> http://www.sigaev.ru/misc/polygon-0.2.gz
> Patch fixes wrong algorithms of contains and overlap operations over
> polygons.
> Regression tests contain an examples of such polygons.
Looks sane in a quick once-over. Please commit.
regards, tom
On Wed, 2009-07-22 at 01:06 +0100, Andrew Gierth wrote:
> I'm prepared to give slightly more consideration to option #3: make
> the new code read the old format as well as the new one. I believe
> (though I have not yet tested) that it is possible to reliably
> distinguish the two with relatively l
Andrew Gierth writes:
> (b) many of the old names are significant collision risks.
What collision risks? PG does not allow loadable libraries to export
their symbols, so I don't see the problem. I recommend just keeping
those things named as they were.
> Certainly when developing this I had _S
> "Tom" == Tom Lane writes:
Tom> Andrew Gierth writes:
>> Revision to previous hstore patch to fix (and add tests for) some edge
>> case bugs with nulls or empty arrays.
Tom> I took a quick look at this, and have a couple of beefs
Tom> associated with upgrade risks.
Tom> 1. The patch
So if the general commitfest begins on Sept 1, I recommend that we
hold our sprint the weekend following (saturday 5, say 10am to 4pm
Pacific Standard?). Thoughts?
If we set a date, then people can converge on it.
Pardon me if I am replying without enough context -- I have enough
compelling ti
Robert Haas writes:
> Here is an updated version of my "generic options for explain" patch.
What is the rationale for essentially duplicating defGetBoolean()?
Also, I'd suggest changing the ExplainStmt struct to have a list of
DefElem options instead of hard-wiring the option set at that level.
Greg Stark wrote:
> On Tue, Jul 21, 2009 at 5:51 AM, Robert Haas wrote:
>> I really, really think you need to find someone to help you with the
>> documentation. As I've said before, your English is a lot better than
>> my Japanese, but the current documentation is just hard to read.
>
>
> In ge
Greg Stark wrote:
On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindle wrote:
You also snipped the other scenario I had where row based access control
isn't required but column level and stored procedure level are.
Well we already have column level and stored procedure privileges.
Greg Stark wrote:
> On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindle wrote:
>> You also snipped the other scenario I had where row based access control
>> isn't required but column level and stored procedure level are.
>
> Well we already have column level and stored procedure privileges.
>
>> I u
Andrew Gierth writes:
> Revision to previous hstore patch to fix (and add tests for) some edge
> case bugs with nulls or empty arrays.
I took a quick look at this, and have a couple of beefs associated with
upgrade risks.
1. The patch arbitrarily changes the C-code names of several existing
SQL
On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindle wrote:
> You also snipped the other scenario I had where row based access control
> isn't required but column level and stored procedure level are.
Well we already have column level and stored procedure privileges.
> I understand
> you already have
Peter Eisentraut writes:
> OK, here is an updated patch. It has the setting as enum, completed
> documentation, and libpq support. I'll add it to the commit fest in the hope
> that someone else can look it over in detail.
I found that there is another issue that should be addressed, maybe not
Bernd Helmle wrote:
--On Dienstag, Juli 21, 2009 16:49:45 -0400 Andrew Dunstan
wrote:
You just tested COPY, not pg_dump, right? Some pg_dump numbers would be
interesting, both for text and custom formats.
Plain COPY, yes. I planned testing pg_dump for this round of my review
but ran out
Jeff Davis writes:
> On Tue, 2009-07-21 at 22:01 +0100, Dean Rasheed wrote:
>> I'm not seeing an obvious alternative location to utils/adt. Any advice would
>> be appreciated.
You could make a fair case for either backend/catalog or
backend/commands. Maybe the latter since that's where the core
Itagaki Takahiro writes:
> The attached is a patch to execute lo_unlink() before lo_create()
> in pg_restore.
Applied with corrections --- you had failed to ensure that pg_dump and
pg_restore produce the same output. I also took the opportunity to
schema-qualify the calls of lo_xxx functions, ju
--On Dienstag, Juli 21, 2009 16:49:45 -0400 Andrew Dunstan
wrote:
You just tested COPY, not pg_dump, right? Some pg_dump numbers would be
interesting, both for text and custom formats.
Plain COPY, yes. I planned testing pg_dump for this round of my review but
ran out of time unfortunately.
On Tue, 2009-07-21 at 22:01 +0100, Dean Rasheed wrote:
> OK, I'll try to post an updated patch soon.
>
> I'm not seeing an obvious alternative location to utils/adt. Any advice would
> be appreciated.
My first reaction is utils/misc.
Regards,
Jeff Davis
--
Sent via pgsql-hackers maili
2009/7/21 Jeff Davis :
> On Mon, 2009-07-20 at 17:24 +0100, Dean Rasheed wrote:
>> The same argument could be applied to ruleutils.c, trigfuncs.c and perhaps
>> one or two others.
>>
>> And if not there, where then?
>
> I'm moving the patch status back to "waiting on author" until Alvaro's
> concer
Bernd Helmle wrote:
--On Samstag, Juli 11, 2009 13:40:44 +0300 Peter Eisentraut
wrote:
OK, here is an updated patch. It has the setting as enum, completed
documentation, and libpq support. I'll add it to the commit fest in the
hope that someone else can look it over in detail.
I've sta
On Wednesday 24 June 2009 08:09:57 Robert Haas wrote:
> It appears that, for no particularly good reason, pg_listener.h
> deviates from the usual convention for declaring attribute number
> constants. Normally, it's
>
> #define Anum_{catalog-name}_{column-name} {attribute-number}
>
> pg_listener.
--On Samstag, Juli 11, 2009 13:40:44 +0300 Peter Eisentraut
wrote:
OK, here is an updated patch. It has the setting as enum, completed
documentation, and libpq support. I'll add it to the commit fest in the
hope that someone else can look it over in detail.
I've started looking at this an
Tom Lane wrote:
ANdreas Wenk writes:
actually I discovered that using \du and \dg in psql is providing the
same result:
Yup. The psql documentation says as much.
ok - got it ;-)
Should have read the psql docu ...
I am wondering why there is \dg at all.
Users and groups used to be dist
ANdreas Wenk writes:
> actually I discovered that using \du and \dg in psql is providing the
> same result:
Yup. The psql documentation says as much.
> I am wondering why there is \dg at all.
Users and groups used to be distinct kinds of objects. They aren't
anymore, but people might still b
Jeremy Kerr writes:
> Rather than testing single bits in a loop, change AllocSetFreeIndex to
> use the __builtin_clz() function to calculate the chunk index.
Per subsequent discussion and testing, I've committed a patch that
uses a lookup table instead of depending on __builtin_clz().
http://arch
Em Tue, 21 Jul 2009 16:52:48 -0300, Peter Eisentraut
escreveu:
On Friday 17 July 2009 23:24:16 Dickson S. Guedes wrote:
An use case that i can figure out is an user that connects in multiples
instances in a lot of remote sites (like home-officer for example) and
needs this information in the p
On Friday 17 July 2009 23:24:16 Dickson S. Guedes wrote:
> An use case that i can figure out is an user that connects in multiples
> instances in a lot of remote sites (like home-officer for example) and
> needs this information in the prompt to don't lost the context of your
> work. Is this valid?
Hi,
actually I discovered that using \du and \dg in psql is providing the
same result:
book=# \du
* QUERY **
SELECT r.rolname, r.rolsuper, r.rolinherit,
r.rolcreaterole, r.rolcreatedb, r.rolcanlogin,
r.rolconnlimit,
ARRAY(SELECT b.rolname
FROM pg_catalog.pg_auth_m
On Jul 21, 2009, at 7:47 PM, Alexey Klyukin wrote:
On Jul 21, 2009, at 7:20 PM, Alvaro Herrera wrote:
Alexey Klyukin wrote:
NOTICE: Test from function one
CONTEXT: PL/Perl function "perl_log1"
SQL statement "SELECT * FROM perl_log1()"
PL/Perl function "perl_log1"
Shouldn't the second "
On Mon, 2009-07-20 at 17:24 +0100, Dean Rasheed wrote:
> The same argument could be applied to ruleutils.c, trigfuncs.c and perhaps
> one or two others.
>
> And if not there, where then?
I'm moving the patch status back to "waiting on author" until Alvaro's
concerns are addressed. I don't have an
On Fri, Jul 17, 2009 at 5:26 PM, Martin Pihlak wrote:
> Fujii Masao wrote:
>> http://archives.postgresql.org/pgsql-hackers/2009-07/msg00191.php
>>
>> In line with Robert's suggestion, I submit non-blocking pqcomm patch
>> as a self-contained one.
>>
>
> Here's my initial review of the non-blocking
On Mon, Jul 13, 2009 at 11:32 AM, Heikki
Linnakangas wrote:
> Tom Lane wrote:
>> One thought here is that an AM call isn't really free, and doing two of
>> them instead of one mightn't be such a good idea. I would suggest
>> either having a separate AM entry point to get both bits of data
>> ("amg
Andrew Gierth writes:
> select * from test1 full join test2 using (a,b) where b=1;
> 8.3.1 and CVS HEAD produce a plan in which the b=1 condition is pushed
> down into each side of the join, but 8.3.6 and 8.3.7 do not.
It does what you're expecting in 8.3 branch tip.
http://archives.postgresql.
On Jul 21, 2009, at 7:20 PM, Alvaro Herrera wrote:
Alexey Klyukin wrote:
NOTICE: Test from function one
CONTEXT: PL/Perl function "perl_log1"
SQL statement "SELECT * FROM perl_log1()"
PL/Perl function "perl_log1"
Shouldn't the second "PL/Perl function" line say perl_log2 instead?
Hm, ye
Given:
select * from test1 full join test2 using (a,b) where b=1;
8.3.1 and CVS HEAD produce a plan in which the b=1 condition is pushed
down into each side of the join, but 8.3.6 and 8.3.7 do not.
Is this intentional? I wasn't able to identify anything applicable in
the release notes.
testcase
Alexey Klyukin writes:
> On Jul 21, 2009, at 6:39 PM, Alvaro Herrera wrote:
>> Hmm, in plperl_exec_callback(), does the global variable work if you
>> call one plperl function from another?
> PL/Perl functions can't call each other directly.
Still, it's poor style to rely on the global variable
Alexey Klyukin wrote:
> NOTICE: Test from function one
> CONTEXT: PL/Perl function "perl_log1"
> SQL statement "SELECT * FROM perl_log1()"
> PL/Perl function "perl_log1"
Shouldn't the second "PL/Perl function" line say perl_log2 instead?
--
Alvaro Herrerahttp:/
Peter Eisentraut wrote:
> On Monday 20 July 2009 23:17:30 Andrew Dunstan wrote:
> > I'm not sure where we got to with doing some surgery on the CVS repo so
> > that we can replicate all the tags and branches properly. Has someone
> > fully identified what needs to be fixed so we can have all the ta
On Jul 21, 2009, at 6:39 PM, Alvaro Herrera wrote:
Alexey Klyukin wrote:
Attached is a patch (HEAD) that sets errcontext with PL/Perl function
name, making a distinction between compilation and execution stages,
fixes error messages where function name was already included in the
message itse
p...@thetdh.com writes:
> Normally I'd try a small lookup table (1-byte index to 1-byte value)
> in this case. But if the bitscan instruction were even close in
> performance, it'd be preferable, due to its more-reliable caching
> behavior;
Well, the problem with the bitscan instruction is we
Alexey Klyukin wrote:
> Attached is a patch (HEAD) that sets errcontext with PL/Perl function
> name, making a distinction between compilation and execution stages,
> fixes error messages where function name was already included in the
> message itself and updates regression tests. I'll appr
Am Dienstag, 21. Juli 2009 16:01:01 schrieben Sie:
> Doing it on the client presents a certain challenge when it comes to
> certificates for example - or really in any case where you need to map
> the username to something else. It would be quite convenient to have
> that ability controlled from th
Greg Stark wrote:
On Tue, Jul 21, 2009 at 3:20 PM, Joshua Brindle wrote:
Backing up from KaiGai's description a bit, basically what this is needed
for is storing multilevel data in a single db instance.
For example, you have people logging in from different classifications
(unclass, secret, to
On Tue, Jul 21, 2009 at 10:36 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> Well, the objection remains: We already have dtrace support, and dtrace or
>> dtrace-like systems are spreading to many operating systems, so one wonders
>> whether it is useful to clutter the code with another probing
On Tue, Jul 21, 2009 at 3:20 PM, Joshua Brindle wrote:
>
> Backing up from KaiGai's description a bit, basically what this is needed
> for is storing multilevel data in a single db instance.
>
> For example, you have people logging in from different classifications
> (unclass, secret, top secret, e
Peter Eisentraut wrote:
> I would like to combine all these elements in header and footer, so they both
> say:
>
> Prev Fast Backward Home Fast Forward Next
> TitleP TitleFBTitleFFTitleN
>
> I think this would be much more usable than just the toolt
Normally I'd try a small lookup table (1-byte index to 1-byte value) in this
case. But if the bitscan instruction were even close in performance, it'd be
preferable, due to its more-reliable caching behavior; it should be possible to
capture this at code-configuration time (aligned so as to pro
On Wed, Jul 15, 2009 at 11:20, Tsutomu Yamada wrote:
> Hello,
>
> Alvaro Herrera wrote:
> > Tsutomu Yamada wrote:
> >
> > > This patch using VirtualAlloc()/VirtualFree() to avoid failing in
> > > reattach to shared memory.
> > >
> > > Can this be added to CommitFest ?
> >
> > Since this fi
Hi,
Tom Lane writes:
> For the record, I think this patch is a waste of manpower and we should
> rely on dtrace/systemtap. However, if we are going to make our own
> homegrown substitute for those facilities, a minimum requirement should
> be that it uses the dtrace macros already put into the s
Peter Eisentraut writes:
> Well, the objection remains: We already have dtrace support, and dtrace or
> dtrace-like systems are spreading to many operating systems, so one wonders
> whether it is useful to clutter the code with another probing system instead
> of putting some resources, say, in
Hi,
While trying to build a custom error reporting function for one of our
clients we came across the fact that PL/Perl doesn't set errcontext
that we relied on to get the traceback of running functions. Exactly
the same problem with PL/Python was fixed recently by Peter Eisentraut
(http:
Greg Stark wrote:
On Mon, Jul 20, 2009 at 8:44 PM, Joshua Brindle wrote:
I am capable of speaking for Tresys in this matter. We are very interested
in this work and our US DoD customers need the capabilities that this
project adds (assuming row level access controls are a possibility).
I'm k
Magnus Hagander writes:
> On Tue, Jul 21, 2009 at 15:58, Tom Lane wrote:
>> Are you not describing a behavior that you yourself removed in 8.4,
>> ie the libpq code that looked aside at Kerberos for a username?
> Yes, partially I am :-)
> But it was not documented, and done in a fairly hackish w
Jeremy Kerr writes:
> Thanks for the benchmark app, thought I'd pitch in with some ppc
> results:
It looks to me like we should go with the lookup table approach, as
being the best tradeoff of speed improvement vs platform and compiler
independence. The "float hack" is right out ;-)
I wonder w
On Tue, Jul 21, 2009 at 15:58, Tom Lane wrote:
> Magnus Hagander writes:
>> That said, if there is a username specified it should not be ignored.
>> But if there is none specified, it should work. This works "reasonably
>> well" today, in that we pick the username up from the environment. But
>> I
Magnus Hagander writes:
> That said, if there is a username specified it should not be ignored.
> But if there is none specified, it should work. This works "reasonably
> well" today, in that we pick the username up from the environment. But
> I can see cases where it would be a lot more useful to
Sorry for jumping late into this discussion, but I've been out sailing
for a couple of weeks and stayed away from email :-)
On Mon, Jun 29, 2009 at 21:01, Stephen Frost wrote:
> * Lars Kanis (ka...@comcard.de) wrote:
>> The problem I have, is that I want to use an ordinary windows application,
>>
Itagaki Takahiro writes:
> Jaime Casanova wrote:
>> i think this one could be applied, just as is... there is no need for
>> docs, because the issue being fixed is not documented... maybe that
>> should be in doc of older releases?
> Sure, it was an undocumented behavior. Should we need to add d
Em Tue, 21 Jul 2009 02:07:47 -0300, Itagaki Takahiro
escreveu:
I modified the format logic to use StringInfo and don't cut off the
message in 512 bytes. Key names and values will be never into '...'. I
changed both both report_unique_violation() and ri_ReportViolation().
Hi Takahiro!
Hum,
On Tue, Jul 21, 2009 at 5:51 AM, Robert Haas wrote:
>
> I really, really think you need to find someone to help you with the
> documentation. As I've said before, your English is a lot better than
> my Japanese, but the current documentation is just hard to read.
In general we're very generous w
On Monday 20 July 2009 23:17:30 Andrew Dunstan wrote:
> I'm not sure where we got to with doing some surgery on the CVS repo so
> that we can replicate all the tags and branches properly. Has someone
> fully identified what needs to be fixed so we can have all the tags?
I think this depends on whi
On Tuesday 21 July 2009 09:09:54 Dimitri Fontaine wrote:
> > * Is it ok we have two versions of profiling? (this and dtrace
> > probes)
>
> Can't comment on this, never used dtrace before, don't have a version
> of it on my production systems.
Well, the objection remains: We already have dtra
Greg Williamson wrote:
> KaiGai Kohei asked:
>
>
> <...>
>
>> Here is one idea. I'll upload the draft of the documentation on the
>> wikipage shorter than the current one.
>> Is somebody available to check it from the viewpoint of native English
>> user or database users?
>
> I'll give a shot .
KaiGai Kohei asked:
<...>
>
> Here is one idea. I'll upload the draft of the documentation on the
> wikipage shorter than the current one.
> Is somebody available to check it from the viewpoint of native English
> user or database users?
I'll give a shot ... native english speaker, some exper
Robert Haas wrote:
> 2009/7/20 KaiGai Kohei :
>> Robert Haas wrote:
>>> - row-level security
>>> - complex DDL permissions
>> Is the complex DDL permissions mean something like db_xxx:{create},
>> db_xxx:{relabelfrom relabelto} and others?
>> If so, I can agree to implement these checks at the late
81 matches
Mail list logo
