On Wed, Feb 3, 2010 at 00:46, Alex Hunsaker bada...@gmail.com wrote:
On Tue, Feb 2, 2010 at 22:50, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
On Tue, Feb 2, 2010 at 21:38, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
Yeah the both
On Tue, Jan 19, 2010 at 12:20 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Simon Riggs wrote:
Do we need a new record type for that, is there a handy record type to
bounce from?
After
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
Here's an updated patch. This includes the fix mentioned earlier, some
comment improvements and making CopySnapshot() static again. I also
changed all references to this feature to DML WITH for consistency.
I'm not sure if we want to keep
Hi,
On 2010-02-03 11:04 UTC+2, Takahiro Itagaki wrote:
Hi, I'm reviewing the writable CTE patch. The code logic seems to be
pretty good, but I have a couple of comments about error cases:
* Did we have a consensus about user-visible DML WITH messages?
The term is used in error messages in
On Wed, Feb 3, 2010 at 2:05 AM, Jeff Davis pg...@j-davis.com wrote:
Thanks, very well spotted... Actually the same is true for LISTEN... I
have reworked the patch to do the changes to listenChannels only in
the post-commit functions.
I'm worried that this creates the opposite problem: that a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fujii Masao wrote:
On Mon, Feb 1, 2010 at 7:33 PM, Rafael Martinez
r.m.guerr...@usit.uio.no wrote:
Any thoughts about this? Is this a bug or a 'feature'?
This is not a bug. Since pg_start_backup() uses %X/%X (not %08X/%08X)
as the format of
Fujii Masao wrote:
On Tue, Jan 19, 2010 at 12:20 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Simon Riggs wrote:
Do we need a new record type for that, is there a handy record type to
bounce
On Tue, 2010-02-02 at 20:27 +0200, Heikki Linnakangas wrote:
I'd appreciate it if you could review the relation-specific conflict
patch, 'cos it's still important.
One fundamental gripe I have about that approach is that it's hard to
predict when you will be saved by the cache and when
Michael Meskes írta:
On Tue, Feb 02, 2010 at 03:34:24PM +0100, Boszormenyi Zoltan wrote:
Here's the new patch with the updated regression test.
Committed. Thanks a lot.
Michael
Tom Lane committed a fix for Windows, there was a missing
#include float.h
in execute.c, but there
Fujii Masao wrote:
On Mon, Feb 1, 2010 at 7:40 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
So you get those messages when the table is *not* a temporary table. I
can see now what Fujii was trying to say. His patch seems Ok, though
perhaps it would be better to move the
Fujii Masao wrote:
On Mon, Feb 1, 2010 at 7:40 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
So you get those messages when the table is *not* a temporary table. I
can see now what Fujii was trying to say. His patch seems Ok, though
perhaps it would be better to move
Tatsuo Ishii wrote:
Fujii Masao wrote:
On Mon, Feb 1, 2010 at 7:40 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
So you get those messages when the table is *not* a temporary table. I
can see now what Fujii was trying to say. His patch seems Ok, though
perhaps it would be
On Tue, Feb 2, 2010 at 7:45 PM, Robert Haas robertmh...@gmail.com wrote:
I think you're probably right, but it's not clear what the new name
should be until we have a comment explaining what the function is
responsible for.
So I wrote some comments but wasn't going to repost the patch with the
On Tue, 2 Feb 2010, Robert Haas wrote:
On Sat, Jan 30, 2010 at 1:12 AM, Oleg Bartunov o...@sai.msu.su wrote:
I made available test data I used on
http://www.sai.msu.su/~megera/wiki/2009-07-27,
so anyone can reproduce my results. You can download data
On 02/03/10 12:53, Greg Stark wrote:
On Tue, Feb 2, 2010 at 7:45 PM, Robert Haasrobertmh...@gmail.com wrote:
I think you're probably right, but it's not clear what the new name
should be until we have a comment explaining what the function is
responsible for.
So I wrote some comments but
Can you rename RED and BLACK to RBRED and RBBLACK?
Yes, of course, done.
Any objections to commit?
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
rbtree-0.9.gz
Description: Unix tar
Hi All,
Testcase:
create table foo (a int );
postgres=# SELECT dblink_build_sql_insert('foo','1 2',2,'{\0\,
\a\}','{\99\, \xyz\}');
HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
server closed the connection unexpectedly
This probably means the server terminated abnormally
Greetings, hackers!
The flurry of patches that vendors have recently been making to OpenSSL to
address the potential man-in-the-middle attack during SSL renegotiation have
disabled SSL renegotiation altogether in the OpenSSL libraries. Applications
that make use of SSL renegotiation, such as
Alex Hunsaker wrote:
Well its already in.
Well *that's* easily fixed. I think it's a bad idea, because it's
unclear what you should put there and what the security implications
are.
I can't speak for its virtue, maybe Tim, Andrew?
plperl.on_perl_init runs when
On Wed, Feb 3, 2010 at 6:53 AM, Greg Stark gsst...@mit.edu wrote:
On Tue, Feb 2, 2010 at 7:45 PM, Robert Haas robertmh...@gmail.com wrote:
I think you're probably right, but it's not clear what the new name
should be until we have a comment explaining what the function is
responsible for.
So
2010/2/3 Teodor Sigaev teo...@sigaev.ru:
Can you rename RED and BLACK to RBRED and RBBLACK?
Yes, of course, done.
Any objections to commit?
I would like to see point #2 of the following email addressed before
commit. As things stand, it is not clear (at least to me) whether
this is a win.
Robert Haas escribió:
On Mon, Feb 1, 2010 at 5:23 PM, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
(2) add a very, very large warning that this will crash if you do
almost anything with it.
I think that's an exaggeration. Certain people are known to be using it
quite
On Wed, Feb 03, 2010 at 10:59:57AM +0100, Boszormenyi Zoltan wrote:
Also, another oversight needs fixing on my part, for which
the patch is atttached. The INSERT statement in nan_test.pgc
contains platform dependent strings, inf instead of infinity.
Committed.
Michael
--
Michael Meskes
On Wed, Feb 3, 2010 at 4:09 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
Hi,
On 2010-02-03 11:04 UTC+2, Takahiro Itagaki wrote:
Hi, I'm reviewing the writable CTE patch. The code logic seems to be
pretty good, but I have a couple of comments about error cases:
* Did we have a
On 02/03/10 14:42, Robert Haas wrote:
On Wed, Feb 3, 2010 at 6:53 AM, Greg Starkgsst...@mit.edu wrote:
On Tue, Feb 2, 2010 at 7:45 PM, Robert Haasrobertmh...@gmail.com wrote:
I think you're probably right, but it's not clear what the new name
should be until we have a comment explaining what
On Wed, Feb 3, 2010 at 06:41, Andrew Dunstan and...@dunslane.net wrote:
Alex Hunsaker wrote:
Well its already in.
Well *that's* easily fixed. I think it's a bad idea, because it's
unclear what you should put there and what the security implications
are.
I can't speak for its virtue,
On Wed, Feb 3, 2010 at 5:31 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-02-03 11:04, Takahiro Itagaki wrote:
* The patch includes regression tests, but no error cases in it.
More test cases are needed for stupid queries.
Here's an updated patch.
Some thoughts:
The
On Wed, Feb 3, 2010 at 9:51 AM, Alex Hunsaker bada...@gmail.com wrote:
Hey! I don't think were quite to that nasty B word yet :) I would
argue that treating plperl and plperlu as the same language just
because it shares the same code is a mistake. But I hate the idea of
two
Our manual mentions that you can turn off partial page writes if your
file system guarantees full page writes. We used to mention ReiserFS 4 as
an example, but I have changed that example to mention ZFS, because ZFS
is now more popular.
--
Bruce Momjian br...@momjian.us
On Wed, Feb 3, 2010 at 6:24 AM, Chris Campbell chris_campb...@mac.com wrote:
The flurry of patches that vendors have recently been making to OpenSSL to
address
the potential man-in-the-middle attack during SSL renegotiation have disabled
SSL
renegotiation altogether in the OpenSSL
Robert Haas wrote:
On Wed, Feb 3, 2010 at 6:24 AM, Chris Campbell chris_campb...@mac.com wrote:
The flurry of patches that vendors have recently been making to OpenSSL to
address
the potential man-in-the-middle attack during SSL renegotiation have disabled
SSL
renegotiation altogether in the
2010/2/1 KaiGai Kohei kai...@ak.jp.nec.com:
I again wonder whether we are on the right direction.
I believe the proposed approach is to dump blob metadata if and only
if you are also dumping blob contents, and to do all of this for data
dumps but not schema dumps. That seems about right to me.
Robert Haas robertmh...@gmail.com writes:
Should we think about adding a GUC to disable renegotiation until this
blows over?
Bad idea: once set, it'll never get unset, thus leaving installations
with a weakened security posture even after they've installed fixed
versions of openssl.
On Wed, Feb 3, 2010 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Should we think about adding a GUC to disable renegotiation until this
blows over?
Bad idea: once set, it'll never get unset, thus leaving installations
with a weakened security
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 3, 2010 at 9:51 AM, Alex Hunsaker bada...@gmail.com wrote:
Hey! I don't think were quite to that nasty B word yet :) I would
argue that treating plperl and plperlu as the same language just
because it shares the same code is a mistake.
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2010-02-03 at 01:14 +, Tom Lane wrote:
1. Get rid of inval.c's dependency on relfilenode, by not having it emit
smgr invalidations as a result of relcache flushes. Instead, smgr sinval
messages are sent directly from smgr.c when an actual
On Wed, Feb 3, 2010 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bad idea: once set, it'll never get unset, thus leaving installations
with a weakened security posture even after they've installed fixed
versions of openssl.
regards, tom lane
One might argue that
On Wed, Feb 3, 2010 at 7:00 AM, Oleg Bartunov o...@sai.msu.su wrote:
On Tue, 2 Feb 2010, Robert Haas wrote:
On Sat, Jan 30, 2010 at 1:12 AM, Oleg Bartunov o...@sai.msu.su wrote:
I made available test data I used on
http://www.sai.msu.su/~megera/wiki/2009-07-27,
so anyone can reproduce my
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 3, 2010 at 4:09 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
We have yet to reach a consensus on the name for this feature. I don't
think we have any really good candidates, but I like DML WITH best so far.
Why can't we
Hi,
On 2010-02-03 16:09 UTC+2, Robert Haas wrote:
Why can't we complain about the actual SQL statement the user issued?
Like, say:
INSERT requires RETURNING when used within a referenced CTE
The SELECT equivalent of this query looks like this:
= with recursive t as (select * from t)
On Wed, Feb 3, 2010 at 10:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 3, 2010 at 4:09 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
We have yet to reach a consensus on the name for this feature. I don't
think we have any really
Michael Ledford mledf...@gmail.com writes:
One might argue that the current method is already weakened as it is
measured by the amount of data sent instead of of a length of time. A
session could live a long time under the 512MB threshold depending on
the queries that are being performed.
On Wed, Feb 3, 2010 at 8:48 AM, Robert Haas robertmh...@gmail.com wrote:
2010/2/3 Teodor Sigaev teo...@sigaev.ru:
Can you rename RED and BLACK to RBRED and RBBLACK?
Yes, of course, done.
Any objections to commit?
I would like to see point #2 of the following email addressed before
commit.
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 3, 2010 at 10:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
We could probably make that work for error messages, but what about
documentation? It's going to be awkward to write something like
INSERT/UPDATE/DELETE RETURNING every time we need
On 2010-02-03 16:53 UTC+2, Robert Haas wrote:
Some thoughts:
The comments in standard_ExecutorStart() don't do a good job of
explaining WHY the code does what it does - they just recapitulate
what you can already see from reading the code. You say If there are
DML WITH statements, we
On Wed, 2010-02-03 at 10:48 -0500, Tom Lane wrote:
If so, there is some minor code cleanup and comment changes in
ProcessCommittedInvalidationMessages(). Would you like me to do that, or
should we wait?
I saw that. I didn't touch it because it's not directly relevant to
what I'm doing
On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
On Sat, Jan 30, 2010 at 08:49, Tim Bunce tim.bu...@pobox.com wrote:
SPI functions are not available when the code is run.
Hrm, we might want to stick why in the docs or as a comment somewhere.
I think this was the main
On Wed, Feb 3, 2010 at 11:18 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-02-03 16:53 UTC+2, Robert Haas wrote:
Some thoughts:
The comments in standard_ExecutorStart() don't do a good job of
explaining WHY the code does what it does - they just recapitulate
what you can
On Wed, 3 Feb 2010, Robert Haas wrote:
On Wed, Feb 3, 2010 at 8:48 AM, Robert Haas robertmh...@gmail.com wrote:
2010/2/3 Teodor Sigaev teo...@sigaev.ru:
Can you rename RED and BLACK to RBRED and RBBLACK?
Yes, of course, done.
Any objections to commit?
I would like to see point #2 of the
Here's an overview of where we stand with the remaining 14 patches,
according to my best understanding of the situation.
* Fix large object support in pg_dump - I haven't looked at this, but
it seems like it's relatively close to being ready for commit. We
need to get this one done as it is a
2010/2/3 Oleg Bartunov o...@sai.msu.su:
I would like to see point #2 of the following email addressed before
commit. As things stand, it is not clear (at least to me) whether
this is a win.
http://archives.postgresql.org/pgsql-hackers/2010-01/msg02552.php
Specifically, on this web page:
On 2010-02-03 18:41 UTC+2, Merlin Moncure wrote:
On Wed, Feb 3, 2010 at 11:18 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
Right. The documentation in its current state is definitely lacking.
I've tried to focus all the time I have in making this patch technically
good.
Do you
Is there a way to detect when the SSL library has renegotiation disabled?
(Either at compile-time or runtime, although runtime would definitely be better
because we’ll change our behavior if/when the user updates their SSL library.)
If so, we could skip renegotiation when it’s disabled in the
On Wed, Feb 3, 2010 at 11:18 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
In ExecTopLevelStmtIsReadOnly, you might perhaps want to rephase the
comment in a way that doesn't use the word Ehm. Like maybe: Even
if this function returns true, the statement might still contain
INSERT,
I wrote:
* We can not change the toast rel OID of a shared catalog -- there's no
way to propagate that into the other copies of pg_class. So we need to
rejigger the logic for heap rewriting a little bit. Toast rel swapping
has to be handled by swapping their relfilenodes not their OIDs.
On Wed, Feb 3, 2010 at 11:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Renegotiation after X amount of data is the recommended method AFAIK,
because it limits the volume of data available to cryptanalysis.
What makes you think that elapsed time is relevant at all?
Chris Campbell chris_campb...@mac.com writes:
Is there a way to detect when the SSL library has renegotiation disabled?
Probably not. The current set of emergency security patches would
certainly not have exposed any new API that would help us tell this :-(
If said patches were done properly
On Wed, Feb 3, 2010 at 11:52 AM, Michael Ledford mledf...@gmail.com wrote:
On Wed, Feb 3, 2010 at 11:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Renegotiation after X amount of data is the recommended method AFAIK,
because it limits the volume of data available to cryptanalysis.
What makes you
Tom Lane wrote:
I've been playing around with different alternatives for solving the
problem of toast-pointer OIDs, but I keep coming back to the above as
being the least invasive and most robust answer. There are two basic
ways that we could do it: pass the OID to use to the toast logic,
Tom Lane wrote:
Chris Campbell chris_campb...@mac.com writes:
Is there a way to detect when the SSL library has renegotiation disabled?
Probably not. The current set of emergency security patches would
certainly not have exposed any new API that would help us tell this :-(
If said
On Wed, 2010-02-03 at 11:50 -0500, Tom Lane wrote:
I've concluded that that's too large a change to undertake for 9.0
The purpose of this was to make the big changes in 9.0. If we aren't
going to do that it seems like we shouldn't bother at all.
So why not flip back to the easier approach of
On Wed, Feb 3, 2010 at 09:31, Tim Bunce tim.bu...@pobox.com wrote:
On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
On Sat, Jan 30, 2010 at 08:49, Tim Bunce tim.bu...@pobox.com wrote:
SPI functions are not available when the code is run.
Hrm, we might want to stick why in
On Wed, Feb 3, 2010 at 10:18, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Feb 3, 2010 at 09:31, Tim Bunce tim.bu...@pobox.com wrote:
On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
If we're going to bikeshed the names, I'd suggest:
plperl.on_init - run on
On 02/03/2010 04:49 AM, Rushabh Lathia wrote:
Testcase:
create table foo (a int );
postgres=# SELECT dblink_build_sql_insert('foo','1 2',2,'{\0\,
\a\}','{\99\, \xyz\}');
HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
server closed the connection unexpectedly
Thanks for
On Feb 3, 2010, at 9:21 AM, Alex Hunsaker wrote:
plperl.on_init - run on interpreter creation
plperl.on_plperl_init - run when then specialized for plperl
plperl.on_plperlu_init - run when then specialized for plperlu
Hrm, I think I agree with Tom that we should not
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2010-02-03 at 11:50 -0500, Tom Lane wrote:
I've concluded that that's too large a change to undertake for 9.0
The purpose of this was to make the big changes in 9.0. If we aren't
going to do that it seems like we shouldn't bother at all.
No,
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
The main problem of enabling standard_conforming_strings is
that applications and/or programming language DB APIs are
not prepared to support this. I don't see a change in DB
APIs (that I know of -- Python, Perl, and PHP) to add
support
Greg Sabino Mullane g...@turnstep.com writes:
As one of the more vocal critics of the 8.3 implicit casting
incident, I say +1 on making the change. Unlike casting, it's
a simple GUC change to fix, and now (9.0) is the time to
do it.
Unfortunately, no: six months ago was the time to do it.
On Wed, Feb 03, 2010 at 10:18:51AM -0700, Alex Hunsaker wrote:
On Wed, Feb 3, 2010 at 09:31, Tim Bunce tim.bu...@pobox.com wrote:
On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
On Sat, Jan 30, 2010 at 08:49, Tim Bunce tim.bu...@pobox.com wrote:
SPI functions are not
* Tom Lane t...@sss.pgh.pa.us [100203 12:39]:
Greg Sabino Mullane g...@turnstep.com writes:
As one of the more vocal critics of the 8.3 implicit casting
incident, I say +1 on making the change. Unlike casting, it's
a simple GUC change to fix, and now (9.0) is the time to
do it.
On 02/03/2010 04:49 AM, Rushabh Lathia wrote:
create table foo (a int );
postgres=# SELECT dblink_build_sql_insert('foo','1 2',2,'{\0\,
\a\}','{\99\, \xyz\}');
HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
server closed the connection unexpectedly
The problem exists with
Joe Conway m...@joeconway.com writes:
The problem exists with all three dblink_build_sql_* functions. Here is
a more complete patch. If there are no objections I'll apply this to
HEAD and look at back-patching -- these functions have hardly been
touched since inception.
Do you really need to
On Wed, Feb 3, 2010 at 12:34 PM, Greg Sabino Mullane g...@turnstep.com wrote:
Perl (DBD::Pg anyway) has been compatible since May 2008.
I would interpret that to mean that there is a significant possibility
that a too-old DBD::Pg could get used with a new PostgreSQL, and
therefore we shouldn't
On Wed, Feb 3, 2010 at 10:56, Tim Bunce tim.bu...@pobox.com wrote:
On Wed, Feb 03, 2010 at 10:18:51AM -0700, Alex Hunsaker wrote:
On Wed, Feb 3, 2010 at 09:31, Tim Bunce tim.bu...@pobox.com wrote:
On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
On Sat, Jan 30, 2010 at 08:49,
Tim Bunce tim.bu...@pobox.com writes:
I do see a need for a GRANT check and I'm adding one now (based on
the code in CreateFunction() in functioncmds.c - thanks to RhodiumToad
on IRC for the pointer).
What exactly are you proposing to check, and where, and what do you
think that will fix?
If
On Wed, Feb 3, 2010 at 08:23, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Thu, Jan 14, 2010 at 7:04 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
1. Walsender calls pq_wait() which calls select(), waiting for timeout,
or data to
Tom Lane escribió:
Michael Ledford mledf...@gmail.com writes:
One might argue that the current method is already weakened as it is
measured by the amount of data sent instead of of a length of time. A
session could live a long time under the 512MB threshold depending on
the queries that
Tom Lane wrote:
The argument for doing this now hinges solely on a marketing-driven
choice of version name, and not on any actual evidence that applications
are ready for it. We really need to do this at the start of a devel
and alpha test cycle, not at the end.
Application writers probably
Robert Haas robertmh...@gmail.com wrote:
What harm is being done by the status quo? What benefit do
we get out of changing the default?
I really think that the biggest harm is that people trying to
convert to PostgreSQL, or testing PostgreSQL with their
applications, can get bad behavior
On Wed, Feb 3, 2010 at 11:28, Tom Lane t...@sss.pgh.pa.us wrote:
Tim Bunce tim.bu...@pobox.com writes:
I do see a need for a GRANT check and I'm adding one now (based on
the code in CreateFunction() in functioncmds.c - thanks to RhodiumToad
on IRC for the pointer).
What exactly are you
Alvaro Herrera alvhe...@commandprompt.com writes:
FWIW I think there's another problem with streaming replication here,
which is that most data flows from client to server, so it would take
quite some time for the threshold to be reached. Note that there's no
size check in the libpq frontend
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Perl (DBD::Pg anyway) has been compatible since May 2008.
I would interpret that to mean that there is a significant possibility
that a too-old DBD::Pg could get
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
The argument for doing this now hinges solely on a marketing-driven
choice of version name, and not on any actual evidence that applications
are ready for it. We really need to do this at the start of a devel
and alpha test
On Wed, Feb 3, 2010 at 11:43, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Feb 3, 2010 at 11:28, Tom Lane t...@sss.pgh.pa.us wrote:
Tim Bunce tim.bu...@pobox.com writes:
I do see a need for a GRANT check and I'm adding one now (based on
the code in CreateFunction() in functioncmds.c - thanks
Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
I do see a need for a GRANT check and I'm adding one now (based on
the code in CreateFunction() in functioncmds.c - thanks to RhodiumToad
on IRC for the pointer).
What exactly are you proposing to check, and where, and what do
Andrew Dunstan and...@dunslane.net writes:
%_SHARED has been around for several years now, and if there are genuine
security concerns about it ISTM they would apply today, regardless of
these patches.
Yes. I am not at all happy about inserting nonstandard permissions
checks into GUC assign
On Wed, Feb 3, 2010 at 13:20, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 3, 2010 at 12:34 PM, Greg Sabino Mullane g...@turnstep.com
wrote:
Perl (DBD::Pg anyway) has been compatible since May 2008.
I would interpret that to mean that there is a significant possibility
that a
I still think that changing it now is going to open a can of worms that
we shouldn't be opening at this stage. We have got more than enough to
worry about for 9.0 already. I think it is absolute folly to believe
that this is only going to be a matter of flip the default and nothing
else is
I'd really like to see the data from pg_config and pg_controldata available
through SQL, such as by adding output to pg_show_all_settings(), or adding new
SRFs named something like pg_config() and pg_controldata(). Does this make as
much sense to the rest of the world as it does to me? In
On Feb 3, 2010, at 11:04 AM, Tom Lane wrote:
What I was actually wondering about, however, is the extent to which
the semantics of Perl code could be changed from an on_init hook ---
is there any equivalent of changing search_path or otherwise creating
trojan-horse code that might be executed
On Wed, Feb 3, 2010 at 1:46 PM, Greg Sabino Mullane g...@turnstep.com wrote:
Perl (DBD::Pg anyway) has been compatible since May 2008.
I would interpret that to mean that there is a significant possibility
that a too-old DBD::Pg could get used with a new PostgreSQL, and
therefore we shouldn't
On Wed, Feb 3, 2010 at 1:49 PM, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Feb 3, 2010 at 11:43, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Feb 3, 2010 at 11:28, Tom Lane t...@sss.pgh.pa.us wrote:
Tim Bunce tim.bu...@pobox.com writes:
I do see a need for a GRANT check and I'm adding
Greg Sabino Mullane g...@turnstep.com writes:
Which fallout are we still dealing with? Are you saying that the
developers are not up to the challenge of handling this before 9.0
is released? (If this were anything more than a simple boolean GUC
fix, I would be in your corner).
I'm not certain
On Wed, Feb 3, 2010 at 12:04, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
%_SHARED has been around for several years now, and if there are genuine
security concerns about it ISTM they would apply today, regardless of
these patches.
Yes. I am not at all
On 02/03/2010 01:20 PM, Robert Haas wrote:
I am not sure I really understand why anyone is a rush to make this
change. What harm is being done by the status quo? What benefit do
we get out of changing the default? The major argument that has been
offered so far is that if we don't change it
Alex Hunsaker bada...@gmail.com writes:
On Wed, Feb 3, 2010 at 12:04, Tom Lane t...@sss.pgh.pa.us wrote:
Yes. Â I am not at all happy about inserting nonstandard permissions
checks into GUC assign hooks
I think Tims solution is just to check in plperl.c right before we
eval it so not at SET
On 02/03/2010 02:15 PM, Robert Haas wrote:
The longer we wait before making an
incompatible change, the more people will have adjusted their code to
the new reality (or upgraded their drivers, etc.) and the fewer things
will break.
In my experience, the opposite is true, although in this
Joshua Tolley eggyk...@gmail.com writes:
I'd really like to see the data from pg_config and pg_controldata available
through SQL, such as by adding output to pg_show_all_settings(), or adding new
SRFs named something like pg_config() and pg_controldata(). Does this make as
much sense to the
Rod Taylor escribió:
As much as I would like GUCs to disappear I think this one should
proceed cautiously and probably be a 9.1 or even 9.2 item.
Note that this is *not* about removing the configuration setting, only
about flipping its default value. There has been *no* talk of removing
the
On Wed, Feb 3, 2010 at 2:25 PM, Mark Mielke m...@mark.mielke.cc wrote:
On 02/03/2010 01:20 PM, Robert Haas wrote:
I am not sure I really understand why anyone is a rush to make this
change. What harm is being done by the status quo? What benefit do
we get out of changing the default? The
1 - 100 of 123 matches
Mail list logo
