Thank you all for your comments. I was unaware the ldaps: scheme was
not supposed to be used for LDAP+TLS encryption, but it makes sense now
that you mention it.
There's a nice discussion about how the folks working on mod_ldap for
Apache worked this out way back in 2005:
http://mail-archives.ap
Josh Berkus <[EMAIL PROTECTED]> writes:
> For hackers who don't understand security frameworks, I'm going to make a
> strong case for KaiGai's patch.
> ...
> So it would be much better to have this functionality be "mainstream"
> rather than a fork. If it does get bounced, please do it becuase o
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Are others OK with $COLUMNS controlling screen output and file/pipe, or
> > perhaps COLUMNS controlling only file/pipe, as GNU ls does? I have
> > heard a few people say they only want \pset columns to control
> > file/pipe.
>
> I ag
Bruce Momjian wrote:
> Gregory Stark wrote:
> > "Bruce Momjian" <[EMAIL PROTECTED]> writes:
> >
> > > OK, so COLUMNS should take precedence. I assume this is going to
> > > require us to read the COLUMNS enviroment variable in psql _before_
> > > readline sets it, and that COLUMNS will only affec
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are others OK with $COLUMNS controlling screen output and file/pipe, or
> perhaps COLUMNS controlling only file/pipe, as GNU ls does? I have
> heard a few people say they only want \pset columns to control
> file/pipe.
I agree with the latter. Anyone w
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > OK, so COLUMNS should take precedence. I assume this is going to
> > require us to read the COLUMNS enviroment variable in psql _before_
> > readline sets it, and that COLUMNS will only affect screen output, like
> > ioctl()
Bryce Nesbitt wrote:
>
> > OK, so COLUMNS should take precedence. I assume this is going to
> > require us to read the COLUMNS environment variable in psql _before_
> > readline sets it, and that COLUMNS will only affect screen output, like
> > ioctl(). Is that consistent?
> >
> This whole th
On Mon, 5 May 2008, Tom Lane wrote:
elog() should not be used for user-facing errors. I couldn't easily
tell just which of the messages are likely to be seen by users and
which ones should be "can't happen" cases, but certainly there are
a whole lot of these that need to be ereport()s. Likely
KaiGai Kohei <[EMAIL PROTECTED]> writes:
> I updated the series of SE-PostgreSQL patches for the latest pgsql-8.4devel
> tree.
I tried to do a bit of testing of this, but it does not work on current
Fedora 8, because the policy module doesn't build:
[EMAIL PROTECTED] sepgsql-policy]$ make
make -
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> OK, so COLUMNS should take precedence. I assume this is going to
> require us to read the COLUMNS enviroment variable in psql _before_
> readline sets it, and that COLUMNS will only affect screen output, like
> ioctl(). Is that consistent?
What are
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> How often do people code comments into prepare statements in perl
> or the equivalent in java, ruby, etc?
>
> Do you put comments in your perl prepare statements?
Does it matter? It shouldn't. They are comments.
> If comments count as a stat
Magnus Hagander wrote:
> Magnus Hagander wrote:
> > Tom Lane wrote:
> > > Magnus Hagander <[EMAIL PROTECTED]> writes:
> > > > While looking over the statistics-for-functions patch
> > > > (http://archives.postgresql.org/pgsql-patches/2008-03/msg00300.php),
> > > > I came back to a thought I've had
Folks,
I'd like to make it possible to see qualifiers from inside functions
in PostgreSQL. For my particular case, and for dblink, it would
allow user-space code to some remove bottlenecks which make currently
make inter-DBMS communication extremely inefficient.
The current code returns one (pot
Chris Browne wrote:
[EMAIL PROTECTED] (Florian Weimer) writes:
* Thomas Mueller:
What do you think about it? Do you think it makes sense to implement
this security feature in PostgreSQL as well?
Can't this be implemented in the client library, or a wrapper around it?
A simple
Tom Lane wrote:
Darren Reed <[EMAIL PROTECTED]> writes:
This might seem sillly, but...
...are comments going to be considered statements for the purpose of
this knob?
(hoping the anwer is "yes")
Are you trying to say we should forbid comments? No thank you.
No.
When psql (for
[EMAIL PROTECTED] (Florian Weimer) writes:
> * Thomas Mueller:
>
>> What do you think about it? Do you think it makes sense to implement
>> this security feature in PostgreSQL as well?
>
> Can't this be implemented in the client library, or a wrapper around it?
> A simple approximation would be to
Darren Reed <[EMAIL PROTECTED]> writes:
> This might seem sillly, but...
> ...are comments going to be considered statements for the purpose of
> this knob?
> (hoping the anwer is "yes")
Are you trying to say we should forbid comments? No thank you.
regards, tom lane
--
Andreas Pflug wrote:
With ldaps on port 636 STARTTLS should NEVER be issued, so the
protocol identifier ldaps should be sufficient as "do not issue
STARTTLS" flag. IMHO the current pg_hba.conf implementation doesn't
follow the usual nomenclatura; ldap with TLS is still ldap. Using
ldaps as ind
Zeugswetter Andreas OSB sIT wrote:
Do we want the following:
1. pg_dump issues "set statement_timeout = 0;" to the
database prior to
taking its copy of data (yes/no/default-but-switchable)
2. pg_dump/pg_restore issue "set statement_timeout = 0;" in
text mode
This might seem sillly, but...
...are comments going to be considered statements for the purpose of
this knob?
(hoping the anwer is "yes")
Darren
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgs
Tom Lane wrote:
> I think a better idea is to embed the flag in the pg_hba.conf entry
> itself. Perhaps something like "ldapso:" instead of "ldaps:" to
> indicate "old" secure ldap protocol, or include another parameter
> in the URL body.
FWIW, I'm working on a proposal to change how pg_hba.conf
Tom Lane wrote:
stephen layland <[EMAIL PROTECTED]> writes:
I've written a quick patch against the head branch (8.4DEV, but it also
works with 8.1.3 sources) to fix LDAP authentication support to
work with LDAPS servers that do not need start TLS. I'd be interested
to hear your opinions on
> > Do we want the following:
>
> > 1. pg_dump issues "set statement_timeout = 0;" to the
> database prior to
> > taking its copy of data (yes/no/default-but-switchable)
> > 2. pg_dump/pg_restore issue "set statement_timeout = 0;" in
> text mode
> > output (yes/no/default-but-switchable)
> >
23 matches
Mail list logo
