2009/9/24 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patch is revised from the previous revision at the following
points:
- The largeobject_compat_acl is renamed to largeobject_check_acl.
Its default is on, and turning it off means the largeobject stuff
performs in compatible mode
Hello hackers,
I really appreciate Mr. Cecchet’s effort to establish the wiki page
(working_with_eclipse, http://archives.postgresql.org/pgsql-hackers/2008-
10/msg00312.php).
I set up my PostgreSQL development environment with Eclipse, following the
page’s instructions.
However, I’m
On Sat, Aug 8, 2009 at 7:47 PM, Mark Kirkwood mar...@paradise.net.nz wrote:
Patch with max(wait time).
Still TODO
- amalgamate individual transaction lock waits
- redo (rather ugly) temporary pg_stat_lock_waits in a form more like
pg_locks
This version has the individual transaction
At 2009-09-27 12:54:48 -0400, robertmh...@gmail.com wrote:
If this patch looks good now, can you mark it Ready for Committer in
the CommitFest app?
Done.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Thanks for your comments.
Jaime Casanova wrote:
2009/9/24 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patch is revised from the previous revision at the following
points:
- The largeobject_compat_acl is renamed to largeobject_check_acl.
Its default is on, and turning it off means the
/users/heikki/postgres.git.
Further fixes extracted from above repository attached..
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
hs-riggs-branch-20090928.tar.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Sun, Sep 27, 2009 at 23:03, Robert Haas robertmh...@gmail.com wrote:
On Sun, Sep 27, 2009 at 4:54 PM, Peter Eisentraut pete...@gmx.net wrote:
On Sun, 2009-09-27 at 16:15 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Then why not send everything to syslog and have syslog
Sorry, I'm having trouble understanding what you're driving at here.
I think we should just not allow named notation to be combined with
VARIADIC, at least for a first version of this feature, either when
defining a function or when calling one. We can consider relaxing
that restriction at a
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
I removed hunks by sql_help.c and fix a typo in documentation.
An updated patch attached.
Brendan Jurd dire...@gmail.com wrote:
With the sql_help.c changes removed, the patch applied fine and
testing went well.
I noticed only the following in the new documentation in CREATE TABLE:
-
On 28 sep 2009, at 11.54, Albe Laurenz laurenz.a...@wien.gv.at
wrote:
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.
At 2009-09-12 13:17:50 -0400, and...@dunslane.net wrote:
I have just noticed, somewhat to my chagrin, that while in a plperl
function that returns an array type you can return a perl arrayref,
like this:
return [qw(a b c)];
if the function returns a setof an array type you cannot do
On Mon, Sep 28, 2009 at 5:22 AM, Magnus Hagander mag...@hagander.net wrote:
On Sun, Sep 27, 2009 at 23:03, Robert Haas robertmh...@gmail.com wrote:
On Sun, Sep 27, 2009 at 4:54 PM, Peter Eisentraut pete...@gmx.net wrote:
On Sun, 2009-09-27 at 16:15 -0400, Tom Lane wrote:
Peter Eisentraut
2009/9/28 Robert Haas robertmh...@gmail.com:
On Mon, Sep 28, 2009 at 5:22 AM, Magnus Hagander mag...@hagander.net wrote:
On Sun, Sep 27, 2009 at 23:03, Robert Haas robertmh...@gmail.com wrote:
On Sun, Sep 27, 2009 at 4:54 PM, Peter Eisentraut pete...@gmx.net wrote:
On Sun, 2009-09-27 at 16:15
Albe Laurenz wrote:
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
On Mon, Sep 28, 2009 at 6:51 AM, Magnus Hagander mag...@hagander.net wrote:
I think it's better to spool the log messages to files, and then let
the external utility read the files. The external utility can still
fall behind, but even if it does the cluster will continue running.
The
Andrew Dunstan escribió:
Albe Laurenz wrote:
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
* Magnus Hagander (mag...@hagander.net) wrote:
Are there better ways?
Isn't there some library we can link with and (conditionally) use? I
believe windows exposes api function(s) to let you verify password
complexity - I'm sure there is something similar available on unix,
hopefully
In response to Ing. Marcos L. Ortíz Valmaseda mlor...@uci.cu:
Andrew Dunstan escribió:
Albe Laurenz wrote:
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
On Sun, Sep 27, 2009 at 11:31 PM, Jeff Davis pg...@j-davis.com wrote:
On Sun, 2009-09-27 at 22:40 -0400, Robert Haas wrote:
Apparently, CommitFest
no longer means a time when people put aside their own patches to
review those of others; it seems now to mean a time when 87% of the
patch
2009/9/28 Stephen Frost sfr...@snowman.net:
* Magnus Hagander (mag...@hagander.net) wrote:
Are there better ways?
Isn't there some library we can link with and (conditionally) use? I
believe windows exposes api function(s) to let you verify password
complexity - I'm sure there is something
Ing. Marcos L. Ortíz Valmaseda wrote:
My vote is for #3, if anything.
You have to analyze all points before to do this. I vote too for the
third option, but you have to be clear that how do you ´ll check the
weakness of the password:
1- For example: the length should be greater that 6
2009/9/28 Andrew Dunstan and...@dunslane.net:
Ing. Marcos L. Ortíz Valmaseda wrote:
My vote is for #3, if anything.
You have to analyze all points before to do this. I vote too for the third
option, but you have to be clear that how do you ´ll check the weakness of
the password:
1-
[ please trim the quoted material a bit, folks ]
Magnus Hagander mag...@hagander.net writes:
2009/9/28 Robert Haas robertmh...@gmail.com:
The problem with having the syslogger send the data directly to an
external process is that the external process might be unable to
process the data as
Andrew Dunstan and...@dunslane.net writes:
Albe Laurenz wrote:
1) One could have a set of GUCs like min_password_length,
min_password_nonchars and similar that everybody
could configure. This is not extremely flexible though.
2) Another idea would be a GUC that contains a regular
expression
On Sat, 2009-09-26 at 15:35 -0600, Joshua Tolley wrote:
On Sat, Sep 26, 2009 at 11:43:46AM -0400, Tom Lane wrote:
complete but more complex solution. (dup2 works on Windows, no?)
Unless I'm misreading syslogger.c, dup2() gets called on every platform.
I've started the wiki page in
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.
regards, tom lane
--
Sent via pgsql-hackers
Albe Laurenz laurenz.a...@wien.gv.at writes:
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.
I'm
On Mon, Sep 28, 2009 at 4:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Albe Laurenz laurenz.a...@wien.gv.at writes:
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
Dave Page dp...@pgadmin.org writes:
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
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
On Mon, Sep 28, 2009 at 11:31 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
Robert Haas wrote:
So I think we should at a minimum ask the patch author to (1) fix the
explain bugs I found and (2) update the README, as well as (3) revert
needless whitespace changes - there are a couple
On Mon, 2009-09-28 at 11:50 +0200, Pavel Stehule wrote:
This is maybe too strict. I thing, so safe version is allow variadic
packed parameter with VARIADIC keyword as Jeff proposes.
The combination of variadic parameters and named call notation is
somewhat strange, on second thought. Can you
2009/9/28 Jeff Davis pg...@j-davis.com:
On Mon, 2009-09-28 at 11:50 +0200, Pavel Stehule wrote:
This is maybe too strict. I thing, so safe version is allow variadic
packed parameter with VARIADIC keyword as Jeff proposes.
The combination of variadic parameters and named call notation is
- Forwarded message from Robert Haas robertmh...@gmail.com -
Date: Sun, 27 Sep 2009 12:52:35 -0400
From: Robert Haas robertmh...@gmail.com
To: Boszormenyi Zoltan z...@cybertec.at
Cc: Dan Colish d...@unencrypted.org, pgsql-rrreview...@postgresql.org,
Jeff Janes
On Mon, 2009-09-28 at 18:23 +0200, Pavel Stehule wrote:
when I though about control, I found so syntax with mandatory VARIADIC
is difficult implementable. So probably the most feasible solution for
this moment is to discard a variadic functions from set of functions
that are callable with
pete...@gmx.net (Peter Eisentraut) writes:
On Fri, 2009-09-25 at 16:59 -0400, Tom Lane wrote:
shakahsha...@gmail.com shakahsha...@gmail.com writes:
From pg_dump/pg_restore section (9.2 of the Todo page on the
PostgreSQL Wiki), is the following item
Add comments to output indicating
Tom Lane escribió:
[ please trim the quoted material a bit, folks ]
Magnus Hagander mag...@hagander.net writes:
2009/9/28 Robert Haas robertmh...@gmail.com:
The problem with having the syslogger send the data directly to an
external process is that the external process might be unable to
On Mon, Sep 28, 2009 at 1:07 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Tom Lane escribió:
[ please trim the quoted material a bit, folks ]
Magnus Hagander mag...@hagander.net writes:
2009/9/28 Robert Haas robertmh...@gmail.com:
The problem with having the syslogger send the data
2009/9/28 Jeff Davis pg...@j-davis.com:
On Mon, 2009-09-28 at 18:23 +0200, Pavel Stehule wrote:
when I though about control, I found so syntax with mandatory VARIADIC
is difficult implementable. So probably the most feasible solution for
this moment is to discard a variadic functions from set
Petr Jelinek pjmo...@pjmodos.net writes:
[ latest version of DefaultACLs patch ]
I started looking through this patch, but found that it's not nearly
ready to commit :-(. The big missing piece is that there's no pg_dump
support for default ACLs. That's a bigger chunk of code than I have
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
This is the same issue already raised with respect to syslog versus
syslogger, ie, some people would rather lose log data than have the
backends block waiting for it to be written.
That could be made configurable; i.e. let
(resent to -hackers)
I just applied and tested the new patch. Everything works great.
The only thing I would change now is some of the comments.
1). On line 289, one of the regression test comments got copied:
+ move forward in c; --should be at '5'
change to:
+ move
On Mon, 2009-09-28 at 19:26 +0200, Pavel Stehule wrote:
Also, you should consistently pass NIL when you mean an empty list, but
sometimes you pass NULL to FuncnameGetCandidates().
It's bug, where is it?
In regproc.c.
Jeff
--
Sent via pgsql-hackers mailing list
On 9/28/09, Tom Lane t...@sss.pgh.pa.us 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.
Hmm... Looking at
Abhijit Menon-Sen wrote:
The fix is fairly small (see attached) although I need to check with
some perlguts guru to see if I need to decrement a refcounter here or
there.
Slightly simpler patch attached (and tested).
Thanks. Committed.
cheers
andrew
--
Sent via pgsql-hackers
Robert Haas escribió:
On Mon, Sep 28, 2009 at 1:07 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Tom Lane escribió:
[ please trim the quoted material a bit, folks ]
Magnus Hagander mag...@hagander.net writes:
2009/9/28 Robert Haas robertmh...@gmail.com:
The problem with
Tom Lane wrote:
Petr Jelinek pjmo...@pjmodos.net writes:
[ latest version of DefaultACLs patch ]
I started looking through this patch, but found that it's not nearly
ready to commit :-(. The big missing piece is that there's no pg_dump
support for default ACLs. That's a bigger chunk
On Mon, Sep 28, 2009 at 2:13 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
On Mon, Sep 28, 2009 at 1:07 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Tom Lane escribió:
[ please trim the quoted material a bit, folks ]
Magnus Hagander
Marko Kreen mark...@gmail.com writes:
So promoting the ENCRYPTED 'foo' as secure may lure users into
false sense of security, and be lax against sniffing and logfile
protection.
This argument is entirely irrelevant to the point. Yes, ENCRYPTED
doesn't fix everything, but it is still good
On Mon, Sep 28, 2009 at 2:00 PM, Marko Kreen mark...@gmail.com wrote:
So promoting the ENCRYPTED 'foo' as secure may lure users into
false sense of security, and be lax against sniffing and logfile
protection.
ENCRYPTED prevents the user's password from being stolen by a modified server.
2009/9/28 John Naylor jcnay...@gmail.com:
Pavel,
It looks good. My last email didn't go to -hackers, since I wasn't
subscribed. I had to resend to -hackers so there will be a link for
the commitfest page. I think you might have to resend your latest
patch to the list. Sorry!
nothing, patch
There is another large problem, too. The patch seems to have
only half-baked support for global defaults (those not tied to a
specific schema) --- it looks like you can put them in, but half
of the code will ignore them or else fail while trying to use them.
This isn't just a matter of a
Robert Haas wrote:
Can you at least take a stab at it? We can fix your grammar, but
guessing what's going on without documentation is hard.
With some help from David Fetter, I took another try at it. I hope
someone finds this helpful. I'm happy to answer any questions.
Regards,
Marko
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
This is the same issue already raised with respect to syslog versus
syslogger, ie, some people would rather lose log data than have the
backends block waiting for it to be written.
That could be
Josh Berkus j...@agliodbs.com writes:
This isn't just a matter of a few missed cases while coding, I think.
The generic issue that the code doesn't even think about addressing
is which default should apply when there's potentially more than one
applicable default?
I thought the idea was to
Alvaro Herrera wrote:
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
This is the same issue already raised with respect to syslog versus
syslogger, ie, some people would rather lose log data than have the
backends block waiting for it
Robert Haas wrote:
So is this one Ready for Committer?
Here we go, I think this one is ready. In addition to previous patches,
it does:
* Use some techniques from postfix for getting interface addresses.
Couldn't use code outright, due to license incompatibilities.
* Tested on Solaris,
Andrew Dunstan and...@dunslane.net writes:
Alvaro Herrera wrote:
syslog uses a nonblocking file descriptor without a retry loop to
implement their logic. I see no reason we couldn't do that ourselves.
Mixing it with regular blocking code could turn out to be nontrivial,
but I don't think
Tom,
I thought the idea was to simply avoid that situation. Maybe we want to
forget about global defaults if that's the case, and just do the ROLE
defaults.
That seems like a pretty dead-end design.
Well, the whole purpose for DefaultACLs is to simplify administration
for the simplest use
Josh Berkus j...@agliodbs.com writes:
But more generally, this is a fairly large and complicated patch in
comparison to the reward, if the intention is that it will never support
anything more than the one case of IN SCHEMA foo filtering.
I thought we were doing ROLEs?
The owning-ROLE match
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Alvaro Herrera wrote:
syslog uses a nonblocking file descriptor without a retry loop to
implement their logic. I see no reason we couldn't do that ourselves.
Mixing it with regular blocking code could turn out to be
Tom,
The owning-ROLE match is required, else you have issues with exactly
what the ACL really means. What we're discussing is what other filters
might exist to determine which objects are affected. The patch already
tries to handle the cases of all owned objects and all owned objects
in
Whoops I missed this email...
Robert Haas wrote:
Rereading the thread, it seems that the main question is whether there
are any platforms that we support that have neither getifaddrs or
SIOCGIFCONF, or where they don't work properly.
As far as I can tell, there are no non-ancient mainstream
Hi,
Attached is a small doc patch for README at top level, which updates
links for some projects. It could be backpatched, too.
Regards,
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
? If none, it is ready for a committer.
--
Euler Taveira de Oliveira
http://www.timbira.com/
buffer_usage-20090928.diff.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
The case that ENCRYPTED
protects against is database superusers finding out other users'
original passwords, which is a security issue to the extent that those
users have used the same/similar passwords for other systems.
I just want to note that md5 is not much of a protection against this
--On 27. September 2009 21:59:37 -0400 Robert Haas robertmh...@gmail.com
wrote:
Bernd,
Can you review this new version and mark this as Ready for Committer
if it looks OK, or else respond with comments and set it back to
Waiting on Author?
Seems Alvaro forgot to include
On Sep 27, 2009, at 9:19 PM, Tom Lane wrote:
What we seem to be lacking in this case is a good tech-speak
option for the underlying catalog name. I'm still not happy
with having a catalog and a view that are exactly the same
except for s, especially since as Alvaro notes that won't
lead to
It takes about 32 hours to brute force all passwords from [a-zA-Z0-9]
of up to 8 chars in length.
That would be a reason to limit the number of failed connection attempts
from a single source, then, rather than a reason to change the hash
function.
Hmmm, that would be a useful, easy (I think)
Bernd Helmle escribió:
Seems Alvaro forgot to include pg_db_role_setting.h, it doesn't
compile anymore with this error:
Huh, you're right, I did :-( Let me unpack the laptop ...
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command
On Mon, 2009-09-28 at 15:52 -0700, Josh Berkus wrote:
It takes about 32 hours to brute force all passwords from [a-zA-Z0-9]
of up to 8 chars in length.
That would be a reason to limit the number of failed connection attempts
from a single source, then, rather than a reason to change the
Bernd Helmle escribió:
Seems Alvaro forgot to include pg_db_role_setting.h, it doesn't
compile anymore with this error:
Here they are.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
/*
* pg_db_role_setting.c
*
On Mon, 2009-09-28 at 15:52 -0700, Josh Berkus wrote:
It takes about 32 hours to brute force all passwords from [a-zA-Z0-9]
of up to 8 chars in length.
That would be a reason to limit the number of failed connection attempts
from a single source, then, rather than a reason to change the
Jeff Davis wrote:
On Mon, 2009-09-28 at 15:52 -0700, Josh Berkus wrote:
It takes about 32 hours to brute force all passwords from [a-zA-Z0-9]
of up to 8 chars in length.
That would be a reason to limit the number of failed connection attempts
from a single source, then, rather than
Josh Berkus j...@agliodbs.com writes:
Hmmm, that would be a useful, easy (I think) security feature: add a GUC
for failed_logins_allowed.
And the counts would be tracked and enforced where?
regards, tom lane
--
Sent via pgsql-hackers mailing list
Josh Berkus j...@agliodbs.com writes:
I think trying to make this patch a panacea in the first iteration is
liable to backfire.
I did not suggest any such thing --- the current scope of functionality
is fine by me for a first cut. What I *am* saying is that we had better
have some idea of how
On 9/28/09, Josh Berkus j...@agliodbs.com wrote
I already mentioned one case that there's longstanding demand for, which
is to instantiate the correct permissions on new partition child tables.
Wouldn't that be handled by inheritance?
I wish, but no:
marcin mank marcin.m...@gmail.com writes:
The case that ENCRYPTED
protects against is database superusers finding out other users'
original passwords, which is a security issue to the extent that those
users have used the same/similar passwords for other systems.
I just want to note that md5
Euler Taveira de Oliveira eu...@timbira.com wrote:
I'm reviewing your patch. Your patch is in good shape. It applies cleanly. All
of the things are built as intended (including the two contrib modules). It
doesn't include docs but I wrote it. Basically, I produced another patch (that
are
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
BTW, I raised a few issues. Do you have any opinions?
Certainly, though they're my opinions and I don't know if the committers
will agree, but I suspect they will.
* deployment of the source code
The current patch implements all the access
Stephen Frost wrote:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
BTW, I raised a few issues. Do you have any opinions?
Certainly, though they're my opinions and I don't know if the committers
will agree, but I suspect they will.
Thanks for your comments.
* deployment of the source code
On Mon, Sep 28, 2009 at 1:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The generic issue that the code doesn't even think about addressing
is which default should apply when there's potentially more than one
applicable default? As long as there's only global and per-schema
defaults, it's not too
Itagaki Takahiro escreveu:
Thanks. Except choice of words, can I think the basic architecture of
the patch is ok? The codes to handle global variables like ReadBufferCount
and GlobalReadBufferCount could be rewrite in cleaner way if we could
drop supports of
Robert Haas robertmh...@gmail.com writes:
I haven't read the patch, but it seems like one possible solution to
this problem would be to declare that any any DEFAULT PRIVILEGES you
set are cumulative. If you configure a global default, a per-schema
default, a default for tables whose names
Euler Taveira de Oliveira eu...@timbira.com writes:
Itagaki Takahiro escreveu:
Thanks. Except choice of words, can I think the basic architecture of
the patch is ok? The codes to handle global variables like ReadBufferCount
and GlobalReadBufferCount could be rewrite in cleaner way if we could
On Mon, Sep 28, 2009 at 10:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I haven't read the patch, but it seems like one possible solution to
this problem would be to declare that any any DEFAULT PRIVILEGES you
set are cumulative. If you configure a
* Robert Haas (robertmh...@gmail.com) wrote:
One potential trouble spot is that presumably the built-in default
privileges (eg, PUBLIC EXECUTE for functions) would *not* cumulate
with user-specified defaults.
Why not?
How would you have a default that says I *don't* want public execute
On Sunday 27 September 2009 19:03:33 Robert Haas wrote:
On Sun, Sep 27, 2009 at 9:24 PM, Selena Deckelmann
selenama...@gmail.com wrote:
Hi!
On Wed, Sep 23, 2009 at 2:16 AM, Roger Leigh rle...@codelibre.net wrote:
On Fri, Sep 18, 2009 at 11:30:05AM -0700, Selena Deckelmann wrote:
Brad
Jim Cox escribió:
Attached s/b a patch for the 8.5 TODO Add comments to output indicating
version
of pg_dump and of the database server (pg_dump/pg_restore section, 9.2).
Hmm, what happens if you do a pg_dump -Fc? Is this info saved anywhere
in the dump? Surely if thi is useful in the text
90 matches
Mail list logo
