Dear developers of PostgreSQL!
We (City of Vienna) have many Oracle databases, but plan to use
PostgreSQL for our future database installations as much as possible.
The following idea is inspired by Oracle.
We sometimes need to move a database from one machine to another
(hardware old/broken,
Thanks to everybody who answered.
Maybe it is really the best thing to use a tool like postgresql-relay or
pgpool - I will investigate these.
I'm not eager to reinvent the wheel.
We have considered relocating DNS entries, but the problem is that a
changed
DNS entry takes long to propagate; in
I am now in the process of writing a patch against CVS HEAD that
changes fe-connect.c as follows:
- If there is a 'service' option or PGSERVICE is set, AND the
environment
PGLDAPSERVERS is set to a comma separated list of LDAP server URIs,
LDAP name resolution cuts in.
- Before
I have added a configure option --with-openldap to enable the code.
Does that make sense to you?
Should I try to polish and test the code and submit it as a patch
I would still much prefer to see remote config fetching done in a more
general way, using say libcurl (which handles ldap just
Uh, why is it a good idea to overload the service option like that?
ISTM it'd be less confusing to use a separate option. Further I
suggest
that pg_service ought to be handled first, ie, it makes sense to me to
be able to put both the LDAP name and the LDAP server address(es) into
a
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 specific issues
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 in
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. But I can
I have tried the --with-ldap option since I also intend
to submit a patch that uses LDAP functionality.
Compiling src/interfaces/libpq/fe-auth.c on Linux I get
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -fno-strict-aliasing
-I../../../src/include
Compiling src/interfaces/libpq/fe-auth.c on Linux I get
[compiler error]
Sorry to follow myself up, but I was talking about
src/backend/libpq/auth.c
Yours,
Laurenz Albe
---(end of broadcast)---
TIP 4: Have you searched our list archives?
I am game to write up some better instructions for installing
mingw to compile postgresql on Windows if there are any notes
on which packages need to be installed. I have successfully
compiled and installed on Linux.
I would be very grateful for this.
It would also be very helpful to have
I for one am still struggling with Kerberos on Windows, and
it would be a great help for me to know where to get
libraries and headers from.
The pginstaller README might help you - it contains the steps used to
build it for the installer...
One of my problems is that it needs VC++ to
I have tried to compile 8.1.3 with mingw but I am receiving
come errors, I do not know with versions are the correct one.
Could some body tell me the right versions ? and url's to
download from ? please. I searched the mainling lists but it
is not clear.
Magnus Hagander has pointed me
I have included below a fragment of a discussion from the freepascal
mailing
list. Apparently, some folks expect to be able to start multiple
transactions
[...]
inside the *same* database connection.
My feeling is that this is a false problem, caused by some
interbase/firebird
or delphi
Tom Lane wrote:
Dennis Bjorklund [EMAIL PROTECTED] writes:
Could we make BEGIN fail when we already are in a transaction?
We could, but it'd probably break about as many apps as it fixed.
I'd say that a program that issues BEGIN inside a transaction is
already broken, if only by design.
I
Tom Lane wrote:
It ought to be illegal to modify the loop control variable anyway,
IMNSHO - it certainly is in Ada, the distant antecedent of pl/pgsql.
If modifying the loop variable is disallowed in PL/SQL, I'm all for
disallowing it in plpgsql, otherwise not. Anyone have a
recent copy
Andrew Piskorski wrote:
Rod Taylor wrote:
Disk storage is cheap. Disk bandwidth or throughput is very
expensive.
Oracle has included table compression since 9iR2. They report table
size reductions of 2x to 4x as typical, with proportional reductions
in I/O, and supposedly, usually low to
Josh Berkus wrote:
If you only care about Oracle to PostgreSQL (and who wouldn't?), then
it in fact seems desirable for PL/pgSQL to be a superset of PL/SQL.
I agree with David here. We care about the ability to migrate PL/SQL --
PL/pgSQL. We do *not* care about the ability to migrate
Jaime Casanova wrote:
suppose we have something like this:
upd_views=# create table tabla1 (col1 point);
[...]
then, this select will give an error:
upd_views=# select col1, count(*) from tabla1 group by col1;
ERROR: could not identify an ordering operator for type point
HINT: Use an
I have been experimenting with the exploit described in
http://www.postgresql.org/docs/techdocs.50 to see if our databases
are affected.
Server is 8.1.3, database encoding UTF8.
Client is a C program compiled and linked against libpq version 8.1.3
that uses UTF8 encoding.
I sent the following
satoshi nagayasu wrote:
I'm trying to use PAM auth on PostgreSQL, but I still cannot
get success on PAM auth (with PG813 and RHEL3).
pg_hba.conf has
hostpamtest all 0.0.0.0/0 pam
/etc/pam.d/postgresql is
#%PAM-1.0
auth required pam_stack.so
Real time databases needs some other kinds of semantics and
features that postgres don't have.
Postgres don't supports real time constrains semantics in
transactions. In other hands the concurrent transactions
don't wok well based on priorities of task.
The program scheduler of
Peter Eisentraut wrote:
So assuming we allowed units in postgresql.conf, how would you report
them with SHOW?
1. The way they were set (hard)
2. Without units (not user-friendly)
3. Always in base units (seconds or bytes)
4. The largest unit that gives an integer
(4) seems the
Tom Lane wrote:
The point is until that last WAL file is backed up, the whole backup
is
useless. It isn't good policy to have a backup's value be contingent
on
some future event.
You are assuming here that the continuous archiving process is
identical
to the WAL part of the base-backup
Simon Riggs wrote:
Patch included to implement xlog switching, using an xlog record
processing instruction and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL switch any more?
Laurenz
Tim Allen wrote:
Patch included to implement xlog switching, using an xlog record
processing instruction and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL switch any more?
Well,
The procedure entry point ldap_start_tls_sA could not be located in
the
dynamic link library wldap32.dll.
I'd counsel just leaving --with-ldap off until Magnus gets back
from vacation. We can always revert the patch later if he can't
fix it.
Looking at the MSDN documentation it seems
I have realized that my modifications in configure.in and
src/interfaces/libpq/Makefile to link libpq against
OpenLDAP are buggy.
Here is a proposed patch to fix it.
I write this to pgsql-hackers too because I want to share
the difficulty I'm facing - maybe somebody has a better
idea.
To handle
Maybe the following item would look good in a 'new features' list
targeted at the less technically oriented audience:
- LDAP support for authentication and centralized connection management.
Yours,
Laurenz Albe
---(end of broadcast)---
TIP 9: In
Peter Eisentraut wrote:
Am Montag, 4. September 2006 10:23 schrieb Albe Laurenz:
This is just a 'one line' change in the documentation of
the --with-ldap flag of ./configure
Well, if you want to link from the configure option to the place where
the
feature is explained, then that should
Tom Lane wrote on September 04, 2006:
Albe Laurenz [EMAIL PROTECTED] writes:
# The backend doesn't need everything that's in LIBS, however
! LIBS := $(filter-out -lz -lreadline -ledit -ltermcap -lncurses
-lcurses -lldap_r $(PTHREAD_LIBS), $(LIBS))
This seems pretty risky. What
Chris Browne wrote:
I also seem to recall, in past discussions about library matters,
that AIX is more sticky about requiring that libraries be named
expressly.
ecpglib has
SHLIB_LINK = -L../pgtypeslib -lpgtypes $(libpq) \
$(filter -lintl -lssl -lcrypto -lkrb5 -lcrypt -lm, $(LIBS))
Tom Lane wrote:
I have realized that my modifications in configure.in and
src/interfaces/libpq/Makefile to link libpq against
OpenLDAP are buggy.
Here is a proposed patch to fix it.
[...]
# The backend doesn't need everything that's in LIBS, however
! LIBS := $(filter-out -lz -lreadline
Tom Lane wrote:
It builds fine on AIX 5.3 as long as you tell it to link with
libpq.so. Static builds against libpq.a will fail.
Hm. We have been assuming that AIX's problem is that dynamic
libraries
don't remember their dependencies properly, but maybe the real issue
is
that it prefers
Tom Lane wrote:
Here is a new patch that replaces the previous one; it adds two
macros LDAP_LIBS_FE and LDAP_LIBS_BE for frontend and backend,
respectively.
I did not only add them to the Makefile for interfaces/libpq,
but also everywhere something is linked against libpq in case
somebody
Here is a new patch that replaces the previous one; it adds two
macros LDAP_LIBS_FE and LDAP_LIBS_BE for frontend and backend,
respectively.
I did not only add them to the Makefile for interfaces/libpq,
but also everywhere something is linked against libpq in case
somebody links static.
Kevin Brown wrote:
Let me expand a little on some of the peculiarities of
shared libraries on AIX:
- A normal AIX shared library is called libXX.a
It is an 'ar' archive that contains the shared object(s).
Ah, so the problem really boils down to funny naming conventions.
If they use .a
Tom Lane wrote:
In our case, we have libpq.a and libpq.so in the same directory,
so unless you link with -brtl you will get a static link
(because libpq.a is a static library).
I wonder whether we ought to suppress building (or at least
installing)
our .a libraries at all on AIX. Adding
Tom Lane wrote:
The natural way in AIX would be:
- Create libpq.so
- Create libpq.a by 'rm -f libpq.a; ar -rc libpq.a libpq.so'
- Install only libpq.a
Hm. This seems possible with some moderate hacking on Makefile.shlib
(certainly it'd be no more invasive than the existing
The patch did not work for me :-(
My buildfarm members failed in local testing to execute the
install-check, because initdb failed to find libpq.so.
Make check did succeed, so I think there is a possibility of
getting it
working, but it won't be as simple as adding -brtl to the
Tom Lane wrote:
I think there's a reasonable argument that by installing
a .a file that isn't a shared library, we are violating
the platform's conventions.
Hm. This seems possible with some moderate hacking on Makefile.shlib
(certainly it'd be no more invasive than the existing
Tom Lane wrote:
3) Major hacking in Makefile.shlib to achieve the following:
- libXX.so.n is built from libXX.a in the traditional way.
Then libXX.a is deleted, and recreated as archive
containing libXX.so.n.
- Linking takes place withOUT -brtl, but with -blibpath:...
as
Tom Lane wrote:
Ugh. So given that linker behavior, it's basically impossible to
support multiple libpq versions in the same directory anyway on AIX.
It is possible, if you have both versions of the shared object in
the same library. Essentially what I proposed for 3b).
It is the way IBM does
Rocco Altier wrote:
Here is the working one:
initdb needs:
/usr/lib/libc.a(shr.o)
/unix
/usr/lib/libcrypt.a(shr.o)
Here is the broken one:
initdb needs:
../../../src/interfaces/libpq/libpq.so
/usr/lib/libc.a(shr.o)
Bruce Momjian wrote:
I would like to see some comments about AIX linking so we
don't need to
relearn this in 1-2 years.
Something like
http://archives.postgresql.org/pgsql-hackers/2006-09/msg00893.php
or something more comprehensive?
Maybe mentioning LIBPATH and -blibpath: might be good.
Rocco Altier wrote:
pg_regress normally tries to handle this by setting LD_LIBRARY_PATH
... does AIX use that or a similar symbol?
The make check was successful in my previous testing of the last
patch, so it appears that AIX was paying attention to
LD_LIBRARY_PATH.
Anyhow, I have updated
Tom Lane wrote:
The proposed patch to Makefile.shlib makes me gag :-( ...
It is ugly.
lying to make
about what's the purpose of a rule is seldom a good idea. Please try
as attached instead.
I will ASAP.
Also, I am *really* dubious about the change to
ecpg/test/Makefile.regress --- if
I notice that when I run 'make check' on a
statically linked HEAD, it fails during
'createlang' with
== installing plpgsql ==
ERROR: could not access file $libdir/plpgsql: No such file or
directory
command failed:
Peter Eisentraut wrote:
I notice that when I run 'make check' on a
statically linked HEAD, it fails during
'createlang' with
Because createlang relies on *dynamic* loading.
So that is working as designed.
I interpret that as 'static builds for the database
server are not supported'. Ok by
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I have just noticed that there does not seem to be a psql
command line switch to specify a pg_service.conf name
to connect to. I know we can use a PGSERVICE environment
setting instead, but I think we should have
a command line
Chattopadhyay asked:
My application based on Java servlets was running fine with
version PostgreSQL 7.x, but started giving error:
transaction is read-only, in version 8.0 and 8.1. I am
using Suse Linux 9.3/PostgreSQL 8.0 or Suse Linux
10.1/PostgreSQL 8.1. I am using JDBC 3 drivers and
Marlon Petry wrote:
I am trying to develop, a API to carry through backup and
restore through JDBC.
I think that the best form is to use JNI.
Some Suggestion?
Do you mean 'backup' or 'export/dump'?
If you mean 'export', do you need anything besides SQL?
If you mean 'backup', how do you
Can we have the beta1 binaries for Win32 with --with-ldap?
On Windows, the LDAP library is part of the OS, so we won't
incur any undesirable dependencies.
Yours,
Laurenz Albe
---(end of broadcast)---
TIP 4: Have you searched our list archives?
postgres=# select 123.45::money;
ERROR: column 123.45 does not exist
LINE 1: select 123.45::money;
^
postgres=# select $123.45::money;
ERROR: column $123.45 does not exist
LINE 1: select $123.45::money;
^
You are on the wrong mailing list :^) Try
Jonah H. Harris wrote:
I'd like to submit this for 8.4, but I want to ensure that -hackers
at large approve of this feature before starting serious coding.
IMHO, this is a functionality that should be enabled by default (as it
is on most other RDBMS). It would've prevented severe corruption
KaiGai Kohei wrote:
I'm uncertain how Oracle handles the condition on the statement
triggers. But it seems to me WHEN clause on the statement triggers
are nonsense.
SQL CREATE TRIGGER dummy BEFORE DELETE ON employees WHEN (1 = 1)
2 BEGIN
3 END;
4 /
CREATE TRIGGER dummy BEFORE DELETE
Itagaki Takahiro wrote:
I've reviewed your patch. The rough approach looks fine,
but I have some comments about function declarations and coding style.
Thank you for taking the time!
I think I addressed all the shortcomings you mentioned with
the attached patches. I fixed the { alignment; I am
Heikki Linnakangas wrote:
I think it would better to add an explicit isencrypted parameter to
the check_password_hook function, rather than require the module to do
isMD5 on the password. Any imaginable check hook will need to know if
the password is in MD5 format, and the backend already
Itagaki Takahiro wrote:
Looks good. I change status of the patch to Ready for Committer.
Thanks for the help!
BTW, it might not be a work for this patch, we also need to
reject too long VALID UNTIL setting. If the password is
complex, we should not use the same password for a long time.
Tom Lane wrote:
Applied with some minor modifications. Aside from the added valuntil
parameter, I changed the isencrypted parameter to an int with some
#define'd values. It seems easily foreseeable that we'll replace the
MD5 encryption scheme someday, and it'd be good to ensure that this
Peter Eisentraut wrote:
When using the service parameter in a libpq connection (e.g., psql
service=foo), and the service name is not defined in pg_service.conf,
then the setting is silently ignored and the connection proceeds with
whatever other settings and defaults apply. That does not look
abindra wrote:
Next quarter I am planning to do an Independent Study course
where the main objective would be to allow me to get familiar
with the internals of Postgres by working on a project(s). I
would like to work on something that could possibly be
accepted as a patch.
This is (I
Kevin Grittner wrote:
Just to make those who care aware of it, here is Michael Cahill's
Doctoral Thesis based on implementing Serializable Snapshot
Isolation in InnoDB using a refined version of the techniques
previously used in the Berkley DB (and previously discussed on this
list):
Nicolas Barbier wrote:
Quote:
[...]
That sounds like it should actually work.
That boils down to 2PL, using a granularity that is somewhere between
table locks and single-row locks (note that the latter doesn't
correctly enforce serializability, hence something more coarse which
also
Robert Haas wrote:
A predicate can include columns from an index plus others.
Am I missing something?
Hmm, interesting point. In that case you couldn't use the index to
enforce predicate locking under MVCC without disabling HOT. But there
will be other cases where that wouldn't help
Magnus Hagander wrote:
On Wed, Dec 16, 2009 at 20:34, David E. Wheeler wrote:
*** a/doc/src/sgml/hstore.sgml
--- b/doc/src/sgml/hstore.sgml
Heh, interesting. That clearly shouldn't be there. Applied.
Does this count as catch-22?
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing
Bruce Momjian wrote:
I must be missing something but I thought the only problem with our
existing snapshot system was that you could see a row updated after your
snapshot was created, and that the solution to that was to abort the
transaction that would see the new row. Can you tell me what I
Kevin Grittner wrote:
It seems to me that the hard part of this problem is to describe
the general mechanism by which conflicts will be detected, with
specific references to the types of data structures that will be
used to hold that information.
Well, the general approach to tracking SIREAD
Kevin Grittner wrote:
Another interesting thing which crossed my mind (and I should
probably add a section for such things in the wiki) is that, given
the overhead and conflict implications of using table scans in
serializable transactions, we should perhaps try to discourage table
scans from
Robert Haas wrote:
Jeff Davis wrote:
I have a question regarding true serializability and predicate locking.
There's some context on the wiki page:
If you have the following DDL:
create table mytable(mycircle circle);
create index mytable_mycircle_idx on mytable
using gist
Nicolas Barbier wrote:
I don't know if such a thing would be easy to implement in
PostgreSQL, but I had thought that the standard approach to
implement predicate locking is like this:
Whenever you touch (read) a data structure, you tag it with a lock
that prevents anybody else from modifying
Mark Mielke wrote:
On 01/29/2010 09:01 PM, Tom Lane wrote:
Maybe. We concluded in the April 2009 thread that
standard_conforming_strings = ON had gotten little or no field testing,
and I don't see any strong reason to hope that it's gotten much more
since then.
Not to contradict any
Tom Lane wrote:
One way to deal with it would be to expose the whole renegotiation
setting as a user configuratble option. So they can set *when* we
renegotiate, which would also let them turn it off completely.
Well, that might be a reasonable thing to do, because it's not just a
temporary
As demonstrated here:
http://archives.postgresql.org/pgsql-general/2010-02/msg01057.php
it can happen that you end up with a corrupt database
if you use PITR to recover past a hardware failure.
It seems that unique constraints are not verified during
WAL replay.
Is that intentional or an
A. Kretschmer *EXTERN*
Well, I can easily make it do what you expect, and I don't see many
error returns in that area of the code, so I just wrote a patch that
does what you would expect rather than throw an error.
Well, that's great and better than an error, thx.
test= select
Domenico Rotiroti wrote:
I would like to receive comments/suggestions about this
project: http://github.com/drotiro/postpic.
In short, it's an extension that enables image processing
within the database, adding a new type (image) and several functions.
The image is represented by a
Pei He wrote:
I am trying to put the SP-Gist package, a general index framework for
space partitioning trees , into Postgresql source code.
SP-Gist was developed for postgresql 8.0. However, now it does not
work with the new version.
So, for the submitted patch, what version of postgresql
Mark Dilger wrote:
In particular, in UTF8 land I'd have expected the argument of chr()
to be interpreted as a Unicode code point, not as actual UTF8 bytes
with a randomly-chosen endianness.
Not sure what to do in other multibyte encodings.
Not sure what to do in other multibyte encodings
Andrew wrote:
According to RFC 2279, the Euro,
Unicode code point 0x20AC = 0010 1010 1100,
will be encoded to 1110 0010 1000 0010 1010 1100 = 0xE282AC.
IMHO this is the only good and intuitive way for CHR() and ASCII().
It is beyond ludicrous for functions like chr() or ascii() to
-function.htm it says that To use
UTF8, you specify using nchar_cs in the argument list. Does this
mean
that CHR(X) behaves as Tom Lane wants, and NCHR(X) behaves as Albe
Laurenz wants? Vice versa?
That web page is misleading at least, if not downright wrong.
It's just that an Oracle database
When the database uses a single byte encoding, the chr function takes
the binary byte representation as an integer number between 0 and 255
(e.g. ascii code).
When the database encoding is one of the unicode encodings it takes a
unicode code point.
This is also what Oracle does.
Sorry, but
Tatsuo Ishii wrote:
I think we need to continute design discussion, probably
targetting for 8.4, not 8.3.
But isn't a simple fix for chr() and ascii(), which does not
require a redesign, a Good Thing for 8.3 if possible? Something
that maintains as much upward and/or Oracle compatibility as
Martijn van Oosterhout wrote:
So your implemntation is simply:
1. Take number and make UTF-8 string
2. Convert it to database encoding.
Aah, now I can spot where the misunderstanding is.
That's not what I mean.
I mean that chr() should simply 'typecast' to char.
So when the database encoding
Expecting a Quick response.
Don't hold your breath.
Please post questions like this to the JDBC and/or the 'general' mailing
list.
Yours,
Laurenz Albe
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
So, it's needed to change dictinitoption format of snowball
dictionaries to
point both stop-word file and language's name.
Right.
Is there any chance to get support for other languages than English and
Russian into the tsearch2
Tom Lane wrote:
Would it be an option to have a checksum somewhere in each
data block that is verified upon read?
That's been proposed before and rejected before. See the archives ...
I searched for checksum and couldn't find it. Could someone
give me a pointer? I'm not talking about WAL
Dawid Kuroczko wrote:
Then again, apart from libpq I don't see it mentioned anywhere.
[...]
Looking at the 8.3devel documentation...
I think it should be mentioned in 18. Server Configuration. probably
somewhere in 18.3 Connections and Authentication, that there is
a possibility of using
Dawid Kuroczko wrote:
[...] and it also would be valuable to
add into pg_service.conf.sample an example ldap:// stanza, so if
person opens the file, she will be enlightened.
I like that idea.
And a missing feature. Or rather treat it as feature request. :-)
A wildcard entry. I would like
Tom Lane wrote:
Would it be an option to have a checksum somewhere in each
data block that is verified upon read?
That's been proposed before and rejected before. See the
archives ...
I think
the prior discussions were around the same time WAL was initially put
in, and/or when we
Jan Wieck wrote:
Computing a checksum just before writing the block will NOT detect any
faulty memory or Postgres bug that corrupted the block. You will have
a
perfectly fine checksum over the corrupted data.
A checksum only detects corruptions that happen between write and
read.
Most
Tom Lane wrote:
. for chr() under UTF8, it seems to be generally agreed
that the argument should represent the codepoint and the
function should return the correspondingly encoded character.
If so, possible the argument should be a bigint to
accommodate the full range of possible code points.
Andrew Dunstan wrote:
Instead of the code point, I'd prefer the actual encoding of
the character as argument to chr() and return value of ascii().
And frankly, I don't know how to do it sanely anyway. A character
encoding has a fixed byte pattern, but a given byte pattern
doesn't have
a
Tom Lane wrote:
So I'd like to see an actual case made
that there's a strong reason for not requiring FROM/IN in ecpg.
I guess there's only one, compatibility.
Yeah. Are there any other precompilers that actively reject FROM/IN
here? If we're just a bit more strict than they are, it's
Greg Stark wrote:
If you use binary encoding then you don't have to deal with that.
Though I seem to recall there is still a gotcha you have to worry
about if there are nul bytes in your datum. I don't recall exactly
what that meant you had to do though.
As far as I know, it only means that
Tom Lane wrote:
I don't see any reason why not breaking the user visible behavior of
tuples CTID between any two major releases,
Am I completely wet here?
Completely. This is a user-visible behavior that we have encouraged
people to rely on, and for which there is no easy substitute.
Dear hackers,
I have been thinking about ways to have PostgreSQL reject
weak passwords.
I think the standard recommendation is use PAM and LDAP,
but that requires the user to change the password outside
of PostgreSQL. And who would want to setup and maintain an
LDAP server just for this?
Since
Tom Lane wrote:
Actually there's a much bigger problem with asking the backend to reject
weak passwords: what ya gonna do with a pre-MD5'd string? Which is
exactly what the backend is going to always get, in a security-conscious
environment.
You mean if the password is set with
CREATE/ALTER
Tom Lane wrote:
pgAdmin MD5's the passwords if you use the GUI to change them, or when
add a user. It doesn't make any attempt to parse the SQL if you enter
it yourself in the query tool though (nor is it going to).
No, I wouldn't expect it to go that far. My point is just that
In the discussion following
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
the consensus was that a hook that allows you to implement
a password checking routine as a module would not hurt.
So here's the patch.
I don't think there is documentation required;
correct me if I am
Andrew Dunstan wrote:
So here's the patch.
I don't think there is documentation required;
correct me if I am wrong.
How will people know how to use it, or that it's even there without at
least a note in the docs somewhere?
I'd prefer to have an example as a contrib module, as well as
1 - 100 of 457 matches
Mail list logo
