Hi,
Le 21 juil. 09 à 07:57, Itagaki Takahiro a écrit :
Oops, I must fix it. I didn't test well the default stack depth (10).
I'd better not have limitation of condition stack.
I'm glad to hear it's possible to implement without arbitrary limits :)
BTW, I hope I have enough feedbacks from
On Tue, Jul 21, 2009 at 10:38 AM, Robert Haasrobertmh...@gmail.com wrote:
Pavan, are you planning to respond to Alex's comments and/or update this
patch?
Yes, I will. Hopefully by end of this week.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Sent
Robert Haas wrote:
2009/7/20 KaiGai Kohei kai...@ak.jp.nec.com:
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
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 experience
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 ... native
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 dtrace
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 which
On Tue, Jul 21, 2009 at 5:51 AM, Robert Haasrobertmh...@gmail.com 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
Em Tue, 21 Jul 2009 02:07:47 -0300, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp 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
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Jaime Casanova jcasa...@systemguards.com.ec 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
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 Frostsfr...@snowman.net wrote:
* Lars Kanis (ka...@comcard.de) wrote:
The problem I have, is that I want to use an ordinary windows
Magnus Hagander mag...@hagander.net 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
On Tue, Jul 21, 2009 at 15:58, Tom Lanet...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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
Jeremy Kerr j...@ozlabs.org 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 ;-)
Magnus Hagander mag...@hagander.net writes:
On Tue, Jul 21, 2009 at 15:58, Tom Lanet...@sss.pgh.pa.us 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,
Greg Stark wrote:
On Mon, Jul 20, 2009 at 8:44 PM, Joshua Brindlemet...@manicmethod.com 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
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
Peter Eisentraut pete...@gmx.net 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
Hi,
Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jul 15, 2009 at 11:20, Tsutomu Yamadatsut...@sraoss.co.jp wrote:
Hello,
Alvaro Herrera alvhe...@commandprompt.com wrote:
Tsutomu Yamada wrote:
This patch using VirtualAlloc()/VirtualFree() to avoid failing in
reattach to shared memory.
Can this be added to
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
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 tooltips.
On Tue, Jul 21, 2009 at 3:20 PM, Joshua Brindlemet...@manicmethod.com 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,
On Tue, Jul 21, 2009 at 10:36 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net 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
Greg Stark wrote:
On Tue, Jul 21, 2009 at 3:20 PM, Joshua Brindlemet...@manicmethod.com 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
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 the
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
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
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
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 tags?
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 Herrera
Alexey Klyukin al...@commandprompt.com 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
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.
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, yeah,
Andrew Gierth and...@tao11.riddles.org.uk 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.
On Mon, Jul 13, 2009 at 11:32 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com 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
On Fri, Jul 17, 2009 at 5:26 PM, Martin Pihlakmartin.pih...@gmail.com 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
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 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
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
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? Is
Em Tue, 21 Jul 2009 16:52:48 -0300, Peter Eisentraut pete...@gmx.net
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
Jeremy Kerr j...@ozlabs.org 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
ANdreas Wenk a.w...@netzmeister-st-pauli.de 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
Tom Lane wrote:
ANdreas Wenk a.w...@netzmeister-st-pauli.de 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.
--On Samstag, Juli 11, 2009 13:40:44 +0300 Peter Eisentraut
pete...@gmx.net 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
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.h,
Bernd Helmle wrote:
--On Samstag, Juli 11, 2009 13:40:44 +0300 Peter Eisentraut
pete...@gmx.net 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
2009/7/21 Jeff Davis pg...@j-davis.com:
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
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 mailing
--On Dienstag, Juli 21, 2009 16:49:45 -0400 Andrew Dunstan
and...@dunslane.net 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
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp 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
Jeff Davis pg...@j-davis.com 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
Bernd Helmle wrote:
--On Dienstag, Juli 21, 2009 16:49:45 -0400 Andrew Dunstan
and...@dunslane.net 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
Peter Eisentraut pete...@gmx.net 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
On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindlemet...@manicmethod.com 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
Andrew Gierth and...@tao11.riddles.org.uk 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
Greg Stark wrote:
On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindlemet...@manicmethod.com 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
Greg Stark wrote:
On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindlemet...@manicmethod.com 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
Greg Stark wrote:
On Tue, Jul 21, 2009 at 5:51 AM, Robert Haasrobertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
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
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Andrew Gierth and...@tao11.riddles.org.uk 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
Andrew Gierth and...@tao11.riddles.org.uk 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
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 low
Teodor Sigaev teo...@sigaev.ru 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.
Tom == Tom Lane t...@sss.pgh.pa.us 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.
Jeff == Jeff Davis pg...@j-davis.com 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
* 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
On Tue, Jul 21, 2009 at 7:25 PM, Tom Lanet...@sss.pgh.pa.us 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
Dickson S. Guedes lis...@guedesoft.net 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.
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
On Tue, Jul 21, 2009 at 7:47 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 21, 2009 at 7:47 PM, Tom Lanet...@sss.pgh.pa.us 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
On Tue, Jul 21, 2009 at 10:05 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 21, 2009 at 7:47 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Also, I'd suggest changing the ExplainStmt struct to have a list of
DefElem options instead of hard-wiring the option
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
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 that
Robert Haas robertmh...@gmail.com 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
2009/7/14 Jaime Casanova jcasa...@systemguards.com.ec:
On Thu, Mar 26, 2009 at 2:39 AM, higeponhige...@gmail.com 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.
82 matches
Mail list logo
