On Sat, Feb 07, 2009 at 08:31:23PM -0800, David Fetter wrote:
Considering that the entire project ships with a BSD license, which
very specifically allows use of all or any tiniest part of it with
(skipping some legalese) two restrictions: mention PGDG in the
copyright list, and don't sue us
On 8 Feb 2009, at 02:49, Robert Haas robertmh...@gmail.com wrote:
On Feb 7, 2009, at 4:53 PM, Bruce Momjian br...@momjian.us wrote:
we need to add this to the
Features we do not want section of our todo list.
Proprietary compression algorithms, even with Postgresql-specific
license
Why don't we just add an option to pg_dump --use-compress-program, just
like tar and then people can use their compression algorithm of the
week and we don't need to care about the licence or anything.
Can't this be done already?
pg_dump -Z 0 | compression_binary mydump
If -Z is
Martijn van Oosterhout wrote:
Why don't we just add an option to pg_dump --use-compress-program, just
like tar and then people can use their compression algorithm of the
week and we don't need to care about the licence or anything.
It's not like the case of TOAST where it actually needs to
daveg wrote:
I think the context here is for pg_dump only and in that context a faster
compression library makes a lot of sense. I'd be happy to prepare a patch
if the license issue can be accomodated.
Some kind of performance data (space and time) would be required to
support any change in
Peter Eisentraut wrote:
Notice that the thread originally called for lzma support, which is
completely at the opposite end of the spectrum of compression algorithms
in terms of space and time, compared to lzo. So it's not really clear
what the requirements are in the first place.
On Wed, Feb 04, 2009 at 10:23:17PM -0500, Andrew Chernow wrote:
Dann Corbit wrote:
The LZMA SDK is granted to the public domain:
http://www.7-zip.org/sdk.html
I played with this but found the SDK extremely confusing and flat out
horrible. One personal dislike was the unnecessary use of
daveg wrote:
On Wed, Feb 04, 2009 at 10:23:17PM -0500, Andrew Chernow wrote:
Dann Corbit wrote:
The LZMA SDK is granted to the public domain:
http://www.7-zip.org/sdk.html
I played with this but found the SDK extremely confusing and flat out
horrible. One personal dislike
daveg wrote:
On Wed, Feb 04, 2009 at 10:23:17PM -0500, Andrew Chernow wrote:
Dann Corbit wrote:
The LZMA SDK is granted to the public domain:
http://www.7-zip.org/sdk.html
I played with this but found the SDK extremely confusing and flat out
horrible. One personal dislike was
On Sat, Feb 07, 2009 at 02:47:05PM -0500, Bruce Momjian wrote:
daveg wrote:
On Wed, Feb 04, 2009 at 10:23:17PM -0500, Andrew Chernow wrote:
Dann Corbit wrote:
The LZMA SDK is granted to the public domain:
http://www.7-zip.org/sdk.html
I played with this but found the SDK
On 7 Feb 2009, at 21:08, daveg wrote:
That this comes up much to often suggests that there is more than
near
zero interest. Why can only one compression library can be
considered?
We use multiple readline implementations, for better or worse.
I don't see anything wrong with using
That this comes up much to often suggests that there is more than near
zero interest. Why can only one compression library can be considered?
We use multiple readline implementations, for better or worse.
I think the context here is for pg_dump only and in that context a faster
compression
Robert Haas wrote:
That this comes up much to often suggests that there is more than near
zero interest. Why can only one compression library can be considered?
We use multiple readline implementations, for better or worse.
I think the context here is for pg_dump only and in that
On Feb 7, 2009, at 4:53 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
That this comes up much to often suggests that there is more
than near
zero interest. Why can only one compression library can be
considered?
We use multiple readline implementations, for better or worse.
Robert Haas wrote:
have seen nothing like that for 10 years and I doubt I will see
something the next 5. I am thinking
I am doubtful too.
we need to add this to the
Features we do not want section of our todo list.
Proprietary compression algorithms, even with Postgresql-specific
On Sat, Feb 07, 2009 at 08:49:29PM -0500, Robert Haas wrote:
On Feb 7, 2009, at 4:53 PM, Bruce Momjian br...@momjian.us wrote:
we need to add this to the Features we do not want section of our
todo list.
Proprietary compression algorithms, even with Postgresql-specific
license exceptions?
On Sat, Feb 07, 2009 at 08:49:29PM -0500, Robert Haas wrote:
Proprietary compression algorithms, even with Postgresql-specific
license exceptions?
To be fair, lzo is GPL, which is a stretch to consider proprietary.
-dg
--
David Gould da...@sonic.net 510 536 1443510 282
Hi.
Is it in todo or in a plan to implement lmza commpression in pg_dump
backups?
Thanks
Stano
--
Mgr.
Stano LACKO
mobil:
+421 908 175 753
fax.:
+421 2 555 72 676
e-mail: lacko@spacesystems.sk
Stanislav Lacko wrote:
Hi.
Is it in todo or in a plan to implement lmza commpression in pg_dump
backups?
Nope, never heard anything about it.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Bruce Momjian
Sent: Wednesday, February 04, 2009 3:28 PM
To: Stanislav Lacko
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Is a plan for lmza commpression
Dann Corbit wrote:
The LZMA SDK is granted to the public domain:
http://www.7-zip.org/sdk.html
I played with this but found the SDK extremely confusing and flat out horrible.
One personal dislike was the unnecessary use of C++; although it was the
horrible API that turned me off. I'm not
21 matches
Mail list logo
