Hi,
On Fri, Sep 18, 2009 at 7:34 PM, Fujii Masao masao.fu...@gmail.com wrote:
This approach is OK if the stand-alone walreceiver is treated steadily
by the startup process like a child process under postmaster:
* Handling of some interrupts: SIGHUP, SIGTERM?, SIGINT, SIGQUIT...
For
On Fri, 2009-09-18 at 10:22 -0700, Josh Berkus wrote:
Bruce,
CF17/15 to 8/14
Alpha1 by 8/20
CF29/15 to 10/14
Alpha2 by 10/20
CF311/15 to 12/14
Alpha3 by 11/20
CF41/15 to 2/14
Alpha4 by 2/20
Beta1 est. 3/1 to 3/7
Release June,
David Fetter wrote:
I suggest that we start by putting secure hashing algorithms into the
core distribution so, should MD5 ever break, we have real
alternatives, and not done in a panic.
Doing that now would be quite premature. Which algorithm would we choose?
And there is no urgency
On Sat, Sep 19, 2009 at 11:50:35AM -0400, Andrew Dunstan wrote:
David Fetter wrote:
I suggest that we start by putting secure hashing algorithms into the
core distribution so, should MD5 ever break, we have real
alternatives, and not done in a panic.
Doing that now would be quite
On Sat, Sep 19, 2009 at 03:27, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
However, I would prefer to keep the ability to do this:
psql --set hstore_schema='myschema' -f hstore.sql dbname
The logic to do it is a bit ugly, but editing the file to set what schema to
use is even uglier...
David Fetter da...@fetter.org writes:
On Sat, Sep 19, 2009 at 11:50:35AM -0400, Andrew Dunstan wrote:
What benefit would we gain from making general crypto part of the
core?
People may wish to encrypt things in the database.
That is not an argument why it has to be in core rather than an
I realized the truth of $SUBJECT while reading this report:
http://archives.postgresql.org/pgsql-general/2009-09/msg00712.php
In a standalone backend, postgres.c tries to run StartupXLOG after
having done only BaseInit(), which means that we don't have a PGPROC
(hence can't take LWLocks much less
I think the same, These are not arguments to include crypto on the core, due to
then all users have to think on this aspect to build a simple database, so we
would be obligating to the users to use this module.
I´d let this module on the contrib
Regards
The hurry is enemy of the success:
Robert Haas robertmh...@gmail.com writes:
On Fri, Sep 18, 2009 at 3:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
clause_sides_match_join?
Yes, that's perfect.
Going once ... going twice ... sold.
regards, tom lane
--
Sent via pgsql-hackers mailing list
David Fetter wrote:
As for the suggestion that we should put other crypto functions into
the core, AIUI the reason not to is not to avoid problems with US
Export Regulations (after all, we've shipped source tarballs with
it for many years, including from US repositories), but to make it
I think we have a reasonable consensus around the name operator
exclusion constraints, Robert Haas's suggestion. I am OK with that
name, and it got support from David Fetter and Tom Lane. As David Fetter
said, it's useful for the name to hint at the API.
Peter had some reasonable objections to
Jeff Davis pg...@j-davis.com writes:
There's an important unresolved question with this patch that I need to
address, which just came to light: what about functional/expression
indexes?
What about them? It's not clear why you think this requires anything
special.
On the subject of crypto law - the laws have relaxed significantly in
the last decade to the point where it is now generally safe to export
symmetric encryption up to 128 bits (example: AES), and assymetric
encryption up to 1024 bits (example: RSA). Many countries still require
some sort of
On Sat, 2009-09-19 at 14:05 -0400, Tom Lane wrote:
What about them? It's not clear why you think this requires anything
special.
From a syntax standpoint, I need to represent one operator for every
index column involved in the constraint. So, if there's a functional
index on ((a||b)::circle),
Emmanuel Cecchet m...@asterdata.com writes:
[ latest patch version ]
Do we have consensus on the syntax for this patch? In particular,
what about the question of adding CSV_ to all the CSV-specific option
names? Emmanuel argued that this is necessary to avoid confusion if
we someday introduce
Jeff Davis pg...@j-davis.com writes:
On Sat, 2009-09-19 at 14:05 -0400, Tom Lane wrote:
What about them? It's not clear why you think this requires anything
special.
From a syntax standpoint, I need to represent one operator for every
index column involved in the constraint. So, if there's
On Fri, 2009-09-18 at 18:14 -0700, David Fetter wrote:
Here's what came out for Mozilla, which, I hope you'll pardon my
saying so, is a teensy tad more widely used than PostgreSQL has any
plans to become.
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
It's not as if we don't have the ability to measure performance impact.
It's reasonable to make a requirement that new options to COPY
shouldn't slow it down noticeably if those options aren't used. And we
can test that, and even
On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
Boszormenyi Zoltan írta:
Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
The vague consensus for syntax options was that the GUC
'lock_timeout' and WAIT [N] extension (wherever NOWAIT
is allowed) both
On Sat, 2009-09-19 at 15:26 -0400, Tom Lane wrote:
I haven't read the patch, but this whole discussion sounds to me like
it means you're trying to plug things in at the wrong level. Indexes
generally don't care where the values they are storing came from ---
whether it's a simple column or a
On Sat, 2009-09-19 at 10:48 -0700, Jeff Davis wrote:
CONSTRAINT foo_constr (a op, ...)
{ USING INDEX foo_idx | USING method }
I am updating the syntax to be:
CONSTRAINT foo_constr
EXCLUSION (a op, ...) { USING method | INDEX foo_idx };
First, I think EXCLUSION makes a perfect noun
Jeff Davis pg...@j-davis.com writes:
The design is that one backend needs to be able to see values being
inserted by other backends before commit.
I don't understand why this isn't handled exactly the way unique
constraints are done now. Frankly, the amount of added complexity you
propose
On Sat, 2009-09-19 at 16:43 -0400, Tom Lane wrote:
I don't understand why this isn't handled exactly the way unique
constraints are done now. Frankly, the amount of added complexity you
propose below is enough to make me want to reject the patch forthwith;
given that it's going to be a
Emmanuel Cecchet m...@asterdata.com writes:
[ generic copy options patch ]
I went ahead and applied the psql \copy part of this, since that saves
us a couple hundred lines of code regardless of what may or may not
happen on the backend side. There were a couple of minor bugs, and
I also found a
Jeff Davis pg...@j-davis.com writes:
On Sat, 2009-09-19 at 16:43 -0400, Tom Lane wrote:
I don't understand why this isn't handled exactly the way unique
constraints are done now. Frankly, the amount of added complexity you
propose below is enough to make me want to reject the patch forthwith;
Jeff Davis pg...@j-davis.com writes:
I am updating the syntax to be:
CONSTRAINT foo_constr
EXCLUSION (a op, ...) { USING method | INDEX foo_idx };
I'm still acutely uncomfortable with using CONSTRAINT syntax for this.
It is not a constraint per standard, because it's not going to be
On Sat, 2009-09-19 at 18:00 -0400, Tom Lane wrote:
Well, you can't do it *exactly* the same way btree does, but what
I would envision is first insert the index tuple and then do a
dirty-snapshot search for conflicting tuples. The interlock against
conflicting concurrent inserts doesn't need
On Sat, 2009-09-19 at 18:35 -0400, Tom Lane wrote:
I'm still acutely uncomfortable with using CONSTRAINT syntax for this.
It is not a constraint per standard, because it's not going to be
displayable in information_schema. Furthermore, by extending
standardized syntax you run the risk of
Hi,
Petr Jelinek pjmo...@pjmodos.net writes:
I attached current version of the patch. I don't expect this to get
committed or anything, but I'd like other eyes to take a look at it.
I'm reviewing this patch, and have early questions that might allow for
a quick returned with little feedback
Dimitri Fontaine wrote:
So here are the major points about this patch:
- it's missing the returns declaration syntax (default value could be
returns void?)
- it would be much more friendly to users if it had a default output
for queries, the returned object seems a good fit
Steve Prentice prent...@cisco.com writes:
This patch changes plpgsql IN parameters so they are mutable.
I've applied this, since the consensus seemed to be in favor of it.
I decided not to update the docs for this change because the docs
don't currently indicate that an IN parameter is
David E. Wheeler da...@kineticode.com writes:
... I think that this patch is ready for committer review and, perhaps,
committing. The code looks clean (though mainly over my head) and the
functionality is top-notch.
Given the number of questions in your review, I don't think this is
On Sep 19, 2009, at 7:03 PM, Tom Lane wrote:
Given the number of questions in your review, I don't think this is
actually ready to commit. I'm marking it waiting on author instead.
Yes, actually, I had second thoughts about that and meant to change it
myself. Thanks Tom.
David
--
Sent
Andrew Dunstan and...@dunslane.net writes:
Dimitri Fontaine wrote:
So here are the major points about this patch:
- it's missing the returns declaration syntax (default value could be
returns void?)
- it would be much more friendly to users if it had a default output
for queries, the
On Sat, Sep 19, 2009 at 04:40:19PM -0700, Jeff Davis wrote:
On Sat, 2009-09-19 at 18:35 -0400, Tom Lane wrote:
I'm still acutely uncomfortable with using CONSTRAINT syntax for this.
It is not a constraint per standard, because it's not going to be
displayable in information_schema.
Tom Lane napsal(a):
Andrew Dunstan and...@dunslane.net writes:
Dimitri Fontaine wrote:
So here are the major points about this patch:
- it's missing the returns declaration syntax (default value could be
returns void?)
- it would be much more friendly to users if it had a default
On Sat, Sep 19, 2009 at 3:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Emmanuel Cecchet m...@asterdata.com writes:
[ latest patch version ]
Do we have consensus on the syntax for this patch? In particular,
what about the question of adding CSV_ to all the CSV-specific option
names? Emmanuel
On Sat, Sep 19, 2009 at 4:17 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
Boszormenyi Zoltan írta:
Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
The vague consensus for syntax options was that the GUC
On Sat, Sep 19, 2009 at 2:51 PM, Jeff Davis pg...@j-davis.com wrote:
On Sat, 2009-09-19 at 14:05 -0400, Tom Lane wrote:
What about them? It's not clear why you think this requires anything
special.
From a syntax standpoint, I need to represent one operator for every
index column involved in
On Sat, Sep 19, 2009 at 8:03 PM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
PS: I'll go mark as returned with feedback but intend to complete this
review in the following days, by having a look at the code and
documentation. Unless beaten to it, as I won't be able to give accurate
guidance
(This is my review of the latest version of Stef Walter's samehost/net
patch, posted on 2009-09-17. See
http://archives.postgresql.org/message-id/4ab28043.3050...@memberwebs.com
for the original message.)
The patch applies and builds cleanly, and the samehost/samenet keywords
in pg_hba.conf work
41 matches
Mail list logo
