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
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 at
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
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...
That seems like a pre
David Fetter 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 add-on.
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: fo
Robert Haas writes:
> On Fri, Sep 18, 2009 at 3:52 PM, Tom Lane wrote:
>> clause_sides_match_join?
> Yes, that's perfect.
Going once ... going twice ... sold.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
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
easie
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 t
Jeff Davis 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.
regards, tom lane
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 lic
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 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 other copy formats
Jeff Davis 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 a function
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.
>
> http://www.internetnews.com/government/article.php/3839831/Mozilla+Firefox+Cleared+
Tom Lane wrote:
> Josh Berkus 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 make such te
On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan 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 allow
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
On Sat, 2009-09-19 at 10:48 -0700, Jeff Davis wrote:
> CONSTRAINT foo_constr (a , ...)
> { USING INDEX foo_idx | USING method }
I am updating the syntax to be:
CONSTRAINT foo_constr
EXCLUSION (a , ...) { USING method | INDEX foo_idx };
First, I think EXCLUSION makes a perfect noun to
Jeff Davis 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 below is enough to m
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 rel
Emmanuel Cecchet 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 few other simplif
Jeff Davis 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;
>> given t
Jeff Davis writes:
> I am updating the syntax to be:
> CONSTRAINT foo_constr
> EXCLUSION (a , ...) { 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
displayable in infor
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 nee
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 b
Hi,
Petr Jelinek 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 and much work...
Pa
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
Rea
Steve Prentice 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 constant and I did
"David E. Wheeler" 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
actually ready to comm
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 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 returned object
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. F
Tom Lane napsal(a):
Andrew Dunstan 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 r
On Sat, Sep 19, 2009 at 3:10 PM, Tom Lane wrote:
> Emmanuel Cecchet 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 t
On Sat, Sep 19, 2009 at 4:17 PM, Jeff Janes wrote:
> On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan 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] ex
On Sat, Sep 19, 2009 at 2:51 PM, Jeff Davis 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 the cons
On Sat, Sep 19, 2009 at 8:03 PM, Dimitri Fontaine
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 for pursuing effor
(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 a
40 matches
Mail list logo
