>>>I find it hard to imagine LDAP being sensibly use for any other
postgres
>>>purpose than authentication, despite recent flights of fancy on the
list
>>>about storing large slabs of config data there.
>>
>>It can also make sense to get authorization information from LDAP.
>
> Yes, that's true.
Josh Berkus writes:
> Accomodations will range between $50/night to $110 per night depending on
> where you want to stay.
Sometime you ought to clue us in on where the event is being held.
regards, tom lane
---(end of broadcast)--
Greg,
> > What kind of costs are anticipated?
>
> We don't know that yet. We're going to tell as soon as we have a
> reliable calculation.
However, it's looking like registration will be around $175-$200 USD per
developer. Sponsorships may bring that down, but I'm not counting on it.
Accomoda
[moving to -hackers]
Dmitry Karasik wrote:
I have committed the patch and docs for this - it's an important feature
and I would like people banging on it.
I'd like to review the API we provide to plperl, though - I don't like
it much. I think that should be an 8.2 TODO.
Thanks!
If you
"Markus Bertheau" <[EMAIL PROTECTED]> writes:
> this is the plan: In ParseConfigFile, record the fact that the
> variable was set in response to SIG_HUP in the status field
> (GUC_SET_FROM_SIGHUP). After setting all variables in postgresql.conf,
> set all variables that can appear in postgresql.con
Tom Lane wrote:
> Bruce Momjian writes:
> > Code comment patch applied. Thanks.
>
> The comment was in fact correct as it stood, though in different ways
> for the postmaster and backend --- in the postmaster it alludes to the
> fact that we only enable signals at one point in the postmaster loo
Bruno Wolff III wrote:
On Mon, Mar 06, 2006 at 15:00:07 -0500,
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
I find it hard to imagine LDAP being sensibly use for any other postgres
purpose than authentication, despite recent flights of fancy on the list
about storing large slabs of config dat
Bruce Momjian writes:
> Code comment patch applied. Thanks.
The comment was in fact correct as it stood, though in different ways
for the postmaster and backend --- in the postmaster it alludes to the
fact that we only enable signals at one point in the postmaster loop.
In CVS, I have enabled SQL string warnings for 8.2 in postgresql.conf:
escape_string_warning = on
standard_conforming_strings will be off for 8.2, but perhaps default to
'on' for 8.3, depending on user feedback.
--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss
Hannu Krosing wrote:
> ?hel kenal p?eval, E, 2006-03-06 kell 12:12, kirjutas Bruce Momjian:
> > Added to TODO:
> >
> > o Prevent parent tables from altering or dropping constraints
> > like CHECK that are inherited by child tables
> >
> > Dropping constraints should only be
Ühel kenal päeval, E, 2006-03-06 kell 12:12, kirjutas Bruce Momjian:
> Added to TODO:
>
> o Prevent parent tables from altering or dropping constraints
> like CHECK that are inherited by child tables
>
> Dropping constraints should only be possible with CASCADE.
>
> and we
On Mon, Mar 06, 2006 at 15:00:07 -0500,
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> I find it hard to imagine LDAP being sensibly use for any other postgres
> purpose than authentication, despite recent flights of fancy on the list
> about storing large slabs of config data there.
It can al
Ben,
>I'm the CTO of Coverity, Inc., a company that does static source code
> analysis to look for defects in code. You may have heard of us or of our
> technology from its days at Stanford (the "Stanford Checker"). The
> reason I'm writing is because we have set up a framework internally to
>
> >>If your patch is accepted and a dependency on OpenLDAP is
> introduced,
> >>my patch will provide an additional gain with no additional cost.
> >>
> >>
> >
> >Out of curiosity what would an SQL database want with ldap anyways?
> >
> >
> >
> Single Sign On is the obvious answer.
LDAP do
Neil Conway wrote:
On Mon, 2006-03-06 at 11:55 -0300, Alvaro Herrera wrote:
AFAIR they got a private scan done and they fixed the reported defects.
Indeed: EnterpriseDB paid for a license for the Coverity static analysis
tool, and then ran that tool on the open-source Postgres tree. O
Greg Stark wrote:
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
If your patch is accepted and a dependency on OpenLDAP is introduced,
my patch will provide an additional gain with no additional cost.
Out of curiosity what would an SQL database want with ldap anyways?
Single Sign
Hi,
this is the plan: In ParseConfigFile, record the fact that the
variable was set in response to SIG_HUP in the status field
(GUC_SET_FROM_SIGHUP). After setting all variables in postgresql.conf,
set all variables that can appear in postgresql.conf
(GUC_DISALLOW_IN_FILE), don't have their built-
> >> If your patch is accepted and a dependency on OpenLDAP is
> introduced,
> >> my patch will provide an additional gain with no additional cost.
> >
> > Out of curiosity what would an SQL database want with ldap anyways?
> > Is it just a set of bindings for ldap functions for applications?
>
Luke Lonergan wrote:
> I'm asking our performance lead, Ayush Parashar, to develop a talk
> proposal that will discuss performance of Postgres, including
> enhancements like the on-disk bitmap index, sort improvements, etc.
> We'd also like to discuss the business intelligence use-cases and
> wher
Greg Stark wrote:
> I missed that this was happening up here in Canada. How exclusive is
> the guest list for this? Like, are you only expecting 50 top
> contributors by invitation only or is anyone who can make it welcome?
Everyone is hereby invited.
> What kind of costs are anticipated?
We don
Code comment patch applied. Thanks.
---
Markus Bertheau wrote:
> 2006/3/6, Tom Lane <[EMAIL PROTECTED]>:
> >
> > The comment is referring to the control flow in a backend; you're
> > looking at the postmaster's sighup handl
2006/3/6, Tom Lane <[EMAIL PROTECTED]>:
>
> The comment is referring to the control flow in a backend; you're
> looking at the postmaster's sighup handler, which is different.
Then the following comment patch is appropriate, afaics.
Markus Bertheau
Index: src/include/utils/guc.h
=
Patch applied. Thanks.
Backpatched to 8.1.X.
---
Stephen Frost wrote:
> Greetings,
>
> * Stephen Frost ([EMAIL PROTECTED]) wrote:
> > I've now tested this patch at home w/ 8.2HEAD and it seems to fix the
> > bug. I
On Mon, 2006-03-06 at 11:55 -0300, Alvaro Herrera wrote:
> AFAIR they got a private scan done and they fixed the reported defects.
Indeed: EnterpriseDB paid for a license for the Coverity static analysis
tool, and then ran that tool on the open-source Postgres tree. One of
their engineers then wor
Added to TODO:
o Prevent parent tables from altering or dropping constraints
like CHECK that are inherited by child tables
Dropping constraints should only be possible with CASCADE.
and we already have this in TODO:
o %Prevent child tables from altering or droppin
On Mon, 6 Mar 2006, Bruce Momjian wrote:
Andreas Pflug wrote:
Ben Chelf wrote:
Hello PostgreSQL Developers,
I'm the CTO of Coverity, Inc., a company that does static source code
analysis to look for defects in code. You may have heard of us or of our
technology from its days at Stanford (th
>> If your patch is accepted and a dependency on OpenLDAP is introduced,
>> my patch will provide an additional gain with no additional cost.
>
> Out of curiosity what would an SQL database want with ldap anyways?
> Is it just a set of bindings for ldap functions for applications?
No, what I have
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> If your patch is accepted and a dependency on OpenLDAP is introduced,
> my patch will provide an additional gain with no additional cost.
Out of curiosity what would an SQL database want with ldap anyways?
Is it just a set of bindings for ldap function
OTOH neither JBoss, BerkeleyDB, Qt are listed. Is there a pattern here?
http://www.coverity.com/news/news_02_15_05_story_6.html
---(end of broadcast)---
TIP 6: explain analyze is your friend
Alvaro Herrera wrote:
AFAIR they got a private scan done and they fixed the reported defects.
After that they issued a press release telling how little defects they
got, or something ...
OTOH neither JBoss, BerkeleyDB, Qt are listed. Is there a pattern here?
I guess the pattern is obvious in
Andreas Pflug wrote:
> Ben Chelf wrote:
> >Hello PostgreSQL Developers,
> >
> > I'm the CTO of Coverity, Inc., a company that does static source code
> >analysis to look for defects in code. You may have heard of us or of our
> >technology from its days at Stanford (the "Stanford Checker"). The
Andreas Pflug wrote:
> Ben Chelf wrote:
> > Hello PostgreSQL Developers,
> >
> > I'm the CTO of Coverity, Inc., a company that does static source code
> > analysis to look for defects in code. You may have heard of us or of our
> > technology from its days at Stanford (the "Stanford Checker").
Ben Chelf wrote:
Hello PostgreSQL Developers,
I'm the CTO of Coverity, Inc., a company that does static source code
analysis to look for defects in code. You may have heard of us or of our
technology from its days at Stanford (the "Stanford Checker"). The
reason I'm writing is because we ha
Hello PostgreSQL Developers,
I'm the CTO of Coverity, Inc., a company that does static source code
analysis to look for defects in code. You may have heard of us or of our
technology from its days at Stanford (the "Stanford Checker"). The
reason I'm writing is because we have set up a framew
On Mar 6, 2006, at 22:49 , Q Beukes wrote:
Does someone know of a huge load of real life "LIKE" data, maybe in
CSV format that I can download somewhere, to demonstrate certain
design techniques.
Perhaps you might find something useful at the dbsamples project?
http://pgfoundry.org/projects/d
Zeugswetter Andreas DCP SD wrote:
>
> > > But you could do the indexes first and remember how far you
> > can vacuum
> > > the heap later.
> >
> > But the indexes _can't_ be done first; you _first_ need to
> > know which tuples are dead, which requires looking at the
> > table itself.
>
> If
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey,
Does someone know of a huge load of real life "LIKE" data, maybe in
CSV format that I can download somewhere, to demonstrate certain
design techniques.
Enough data to really see an effect of the difference in tables
with/without indexes and so o
> > But you could do the indexes first and remember how far you
> can vacuum
> > the heap later.
>
> But the indexes _can't_ be done first; you _first_ need to
> know which tuples are dead, which requires looking at the
> table itself.
If we already had the "all tuples visible" bitmap I thin
>> I'm almost done with implementing a patch that recognizes
>> LDAP URLs in pg_services.conf and queries an LDAP server for
>> a connection option string.
>>
>> Currently I'm coding against libldap [...]
>
> If you haven't already, look at the ldap auth patch in the queue for
> some win32 spec
39 matches
Mail list logo
