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
On Sat, Feb 07, 2009 at 10:44:48PM -0500, David Lee Lambert wrote:
> In the same spirit as the FreeBSD-native UUID generator that was
> discussed here a couple months ago, I was able to link Postgres 8.4
> against the UUID generator embedded in the Linux ext2fs toolchain.
> My code is posted at
>
On Sat, Feb 07, 2009 at 08:49:29PM -0500, Robert Haas wrote:
> On Feb 7, 2009, at 4:53 PM, Bruce Momjian 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"?
Cons
In the same spirit as the FreeBSD-native UUID generator that was discussed
here a couple months ago, I was able to link Postgres 8.4 against the UUID
generator embedded in the Linux ext2fs toolchain. My code is posted at
http://www.lmert.com/download/pguuid-for-8.4.tar.gz
Unlike on FreeBSD,
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 Postg
On Feb 7, 2009, at 4:53 PM, Bruce Momjian 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.
I think the c
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 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
> compr
Stephen Frost wrote:
-- Start of PGP signed section.
> Bruce, et al,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > \dg [PATTERN]list roles (groups)
> > \du [PATTERN]list roles (users)
>
> Seeing this list reminded me of a pet-peeve.. \du and \dg actually show
>
On Feb 7, 2009, at 12:11 PM, Bruce Momjian wrote:
can we just apply this one and let this discussion off?
or maybe remove the OFFSET part and point to the SQL COMMAND
references page? (doesn't seem appropiate to me to reject the LIMIT
comment and let the other one in there while they are almost
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 st
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
On Sat, Feb 7, 2009 at 2:44 PM, Bruce Momjian wrote:
>> Yikes! The impact of the patch is about what I'd expect, but the fact
>> that planning time has nearly tripled is... way poor. Can you repost
>> the query and the EXPLAIN output for 8.3.5 and CVS HEAD?
>
> Where are we on this: the original
Jaime Casanova wrote:
> On Wed, Feb 4, 2009 at 12:33 PM, Robert Haas wrote:
> >
> > Still, the queries-limit.html page includes this statement: "OFFSET 0
> > is the same as omitting the OFFSET clause." I don't see that there
> > would be anything bad or confusing about changing it to read this wa
Kenneth Marshall wrote:
> I had submitted the documentation change as part of my
> hash function patch but it was removed as not relevant.
> (It wasn't really.) I would basically remove the first
> sentence:
>
> Note: Hash index operations are not presently WAL-logged,
> so hash indexes
Stephen Frost wrote:
-- Start of PGP signed section.
> * David Fetter (da...@fetter.org) wrote:
> > On Sun, Feb 01, 2009 at 04:54:08AM +, Grzegorz Jaskiewicz wrote:
> > > On 23 Jan 2009, at 00:03, Tom Lane wrote:
> > >> Stephen Frost writes:
> > >>> Seeing this list reminded me of a pet-peeve.
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 p
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
Robert Haas wrote:
> On Mon, Feb 2, 2009 at 8:10 PM, Kevin Grittner
> wrote:
> Robert Haas wrote:
> >> running this 5 times each on several queries,
> >> dropping top and bottom results.
> >
> > Running a complex query (posted in previous threads, runs about
> > 300,000 time per day in a pro
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 unneces
Andrew Chernow wrote:
> > going. Also, there is much threading API churn that we haven't been fond
> > of trying to get everything working.
> >
>
> The provided pthreads is 100% busted on unixware. I'd only recommend its use
> to
> someone I don't like :) This is one of several platforms that
Zdenek Kotala wrote:
When we have now collation per database I think following comment is
useless:
* (2) this code is executed in the postmaster, so the setlocale() will
* propagate to forked backends, which aren't going to read this file for
* themselves. (These locale settings are considered
I can confirm your error report, so have applied your patch. Thanks.
---
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> > Oh, another thing -- ecpg has a dependency on libpq, but it is not
> > declared in Makefiles, so
going. Also, there is much threading API churn that we haven't been fond
of trying to get everything working.
The provided pthreads is 100% busted on unixware. I'd only recommend its use to
someone I don't like :) This is one of several platforms that we use the GNU
Pth library as a replace
Andrew Chernow wrote:
>
> > I am afraid this falls in the same category as the HP-UX patch, in that
> > it is for threading on an older platform
>
> Really? It was released in 2004 (maintenance pack 4 released in June 2008).
Oh, I didn't know that. We have had lots of problems with SCO/Unixwa
Zdenek Kotala wrote:
> The current project is not in good shape. Feature freeze is coming and
> nothing is committed. Currently there are three patches in the game:
>
> 1) Space reservation
> http://archives.postgresql.org/pgsql-hackers/2008-12/msg00886.php
> http://archives.postgresql.org/pgsql-h
I am afraid this falls in the same category as the HP-UX patch, in that
it is for threading on an older platform
Really? It was released in 2004 (maintenance pack 4 released in June 2008).
It would be interesting if you could host a web page, perhaps on our
wiki, that lists patches for old
On Sat, Feb 7, 2009 at 9:46 AM, Greg Stark wrote:
> I sent a message describing where I was headed with the code and my
> misgivings with Tom's concerns. I haven't seen any responses.
>
> Hmmm. I can't find my message however so now I'm wondering if it ever hit
> the lists.
I know it did, because
I don't think anyone replied to your questions below so let me try.
I am afraid this falls in the same category as the HP-UX patch, in that
it is for threading on an older platform and is more for a single site
rather than something where more users can benefit.
It would be interesting if you co
Josh Berkus wrote:
> Euler Taveira de Oliveira wrote:
> > Bryce Nesbitt escreveu:
> >> Here's a revision (thanks Robert Treat for the spelling corrextion).
> >> If there are no other objections, how do I nominate it for consideration?
> >>
> > Added to next commit fest [1].
>
> Um, not necessary.
Bernd Helmle wrote:
> --On Donnerstag, Januar 22, 2009 15:30:35 -0500 Andrew Dunstan
> wrote:
>
> >
> > Am I the only person who gets regularly annoyed by pg_get_viewdef()
> > outputting the target list as one long line? I'd like it to put one
> > target per line, indented, if pretty printing.
>
Tom Lane wrote:
> m...@postgresql.org (Magnus Hagander) writes:
> > Explicitly bind gettext to the correct encoding on Windows.
>
> I have a couple of objections to this patch. First, what happens if
> it fails to find a matching table entry? (The existing answer is
> "nothing", but that doesn't
I sent a message describing where I was headed with the code and my
misgivings with Tom's concerns. I haven't seen any responses.
Hmmm. I can't find my message however so now I'm wondering if it ever
hit the lists.
--
Greg
On 6 Feb 2009, at 18:13, Bruce Momjian wrote:
Tom Lane wrote:
Bryce Nesbitt wrote:
> This is a proposed patch to document disabling the statistics collector
> pg_dump activity, and give a bit more visibility to the PGOPTIONS
> environment variable supported by libpq.
>
> It is an alternative to the prior patch, which supplied a --no-stats flag.
>
> This i
Brendan Jurd wrote:
> On Tue, Jan 27, 2009 at 3:25 PM, Brendan Jurd wrote:
> > On Tue, Jan 27, 2009 at 3:05 PM, Tom Lane wrote:
> >>
> >> strncpy is generally deprecated; any remaining uses you find of it
> >> are probably only there for lack of round tuits. Use strlcpy in new
> >> code, unless
Zdenek Kotala wrote:
> When we have now collation per database I think following comment is
> useless:
>
> * (2) this code is executed in the postmaster, so the setlocale() will
> * propagate to forked backends, which aren't going to read this file for
> * themselves. (These locale settings are co
When we have now collation per database I think following comment is
useless:
* (2) this code is executed in the postmaster, so the setlocale() will
* propagate to forked backends, which aren't going to read this file for
* themselves. (These locale settings are considered critical
* compatibili
37 matches
Mail list logo
