On Wed, May 31, 2006 at 11:20:21PM +0200, Magnus Hagander wrote:
> Uh. The installer does *not* include readline.
Terribly sorry, I misinterpreted the thread about it at the beginning
of the year.
http://archives.postgresql.org/pgsql-hackers/2006-02/msg00539.php
Have a nice day,
--
Martijn van
Ali Baba <[EMAIL PROTECTED]> writes:
> i was just trying recursive function invocation and got a server crash when i
> changed a GUC variable max_stack_depth, to a high number.
There's a reason why that variable is a superuser-only setting: you're
supposed to have some clue what you're doing wh
Ali Baba said:
>
> hi,
> i was just trying recursive function invocation and got a server crash
> when i changed a GUC variable max_stack_depth, to a high number.
> fallowing is what i have tried.
>
> select max_val from pg_settings where name='max_stack_depth'; --
> returns 2097151 set max_stack_
hi,i was just trying recursive function invocation and got a server crash when i changed a GUC variable max_stack_depth, to a high number. fallowing is what i have tried.select max_val from pg_settings where name='max_stack_depth'; -- returns 2097151set max_stack_depth=2097151;CREATE OR REPLACE FU
Something like this would be maybe possible, but this select can
return more rows, when the user is connected with more instances...
David Hoksza
>> Hi, I cant find any function, which tells me something like session
>> id. Is there something like that? I need it
Uh. The installer does *not* include readline.
We do include PostGIS, but the PostGIS people themselves don't consider
us GPLed because of that ;-)
That is a tad different. PostgreSQL does not link to Postgis. Readline
does :)
Sincerely,
Joshua D. Drake
Everything else is != GPL.
//
[ moving this thread to -hackers ]
Martijn van Oosterhout writes:
> While you do have a good point about non-binary modules, our module
> handling need some help IMHO. For example, the current hack for CREATE
> LANGUAGE to fix things caused by old pg_dumps. I think that's the
> totally wrong appr
> > >>I wonder if we'd be able to ship gzip with the windows
> installer, to
> > >>insure proper integration.
> > >
> > >'Fraid not. It's GPL'd.
> >
> > Well, one implementation of it is. zlib is new-bsd-ish, though, and
> > includes minigzip, which should be just fine for use in a pipe on
> >
I'm strongly tempted to put src/tutorial/beard.c out of its misery.
It doesn't compile and probably never has --- not only is it missing
needed #includes, but it references a symbol INV_MD that I can find
no trace of anywhere. And it's certainly not a good example of
backend programming style. An
Martijn van Oosterhout wrote:
On Tue, May 30, 2006 at 11:35:12AM -0400, Tom Lane wrote:
FWIW, it looks like a large part of the bloat in the newer file is
in-line documentation, which we hardly need to include in our
distribution. I'll leave it to someone more familiar with Perl to
determine
Dave Page wrote:
It's not about a primarily GUI based OS not being able to do
everything a traditionally command line based OS can do on the
command line, it's about providing a solution that will work on
either and remain portable. Whilst I agree with your objection to
using pg_lzcompress,
On Wed, May 31, 2006 at 01:08:28PM -0700, Steve Atkins wrote:
> On May 31, 2006, at 12:58 PM, Dave Page wrote:
> >On 31/5/06 19:13, "Andreas Pflug" <[EMAIL PROTECTED]> wrote:
> >
> >>I wonder if we'd be able to ship gzip with the windows installer, to
> >>insure proper integration.
> >
> >'Fraid no
On 31/5/06 21:10, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Dave Page writes:
>> Exactly my point; how many production Windows servers do you have with gzip
>> anywhere near them? Andreas' point about pipes is also valid though - it's
>> simply not the norm on Windows as I found when we were por
Hi,
On Tue, 2006-05-30 at 08:29 -0400, Tom Lane wrote:
> ppport.h is throwing warnings when compiling on Fedora Core 5
> (with perl-5.8.8-4). I gather from the comments in the head
> of that file that we ought to look for a newer version.
I've informed Andrew about this, he sent me a patch a few
Alvaro Herrera wrote:
Andrew Dunstan wrote:
But why is that hugely better than piping psql output to gzip?
psql output has already travelled over the network.
As I understand Tom's suggestion, it does not involve compression of
over the wire data. He suggested that on the serve
Dave Page writes:
> Exactly my point; how many production Windows servers do you have with gzip
> anywhere near them? Andreas' point about pipes is also valid though - it's
> simply not the norm on Windows as I found when we were porting Slony
> (more.exe barfs at >8MB being pipe in).
I don't see
Andreas Pflug <[EMAIL PROTECTED]> writes:
> My COPY WITH COMPRESSION is not the same as taking a copy file and
> zipping it; it creates a copy file with BinarySignature that has
> compressed bytes in the data part, thus it can be handled by any client
> app that can stream binary copy files from
> > I wonder if we'd be able to ship gzip with the windows
> installer, to
> > insure proper integration.
>
> 'Fraid not. It's GPL'd.
>
Well, if we want to go down that route, we could probably hack up
something simple around zlib. IIRC, there's even sample code in there
for how to write a gzi
On May 31, 2006, at 12:58 PM, Dave Page wrote:
On 31/5/06 19:13, "Andreas Pflug" <[EMAIL PROTECTED]> wrote:
I wonder if we'd be able to ship gzip with the windows installer, to
insure proper integration.
'Fraid not. It's GPL'd.
Well, one implementation of it is. zlib is new-bsd-ish, th
Greg Stark wrote:
Incidentally, did the following message ever make it to the list? I saw my
carbon copy, but never received it from the list and never received any
responses. Usually any suggestion of making tokens reserved words elicits
screams of objections.
Greg Stark <[EMAIL PROTECTED]> w
Andrew Dunstan wrote:
> David Fetter wrote:
> >As with "in-place upgrades,"[1] the compelling use case is being short
> >on disk space. For somebody with a multi-TB (or whatever figure
> >sounds big this week) PostgreSQL database, it may be impossible to get
> >space for twice or more that. Givi
On 31/5/06 19:13, "Andreas Pflug" <[EMAIL PROTECTED]> wrote:
> I wonder if we'd be able to ship gzip with the windows installer, to
> insure proper integration.
'Fraid not. It's GPL'd.
Regards, Dave.
---(end of broadcast)---
TIP 9: In versions
On 31/5/06 18:28, "Magnus Hagander" <[EMAIL PROTECTED]> wrote:
> Won't help too much, until gzip's output is piped back too, so a
> replacement for COPY .. TO STDOUT COMPRESSED would be
>> COPY ... TO '|
> /bin/gzip |' STDOUT, to enable clients to
receive the
Regarding ALTER TABLE ADD INHERITS, tablecmds.c has the following comment for
when it's creating a table that inherits some columns:
*The order in which the attributes are inherited is very important.
*Intuitively, the inherited attributes should come first. If a table
*
I've been thinking about the planner's costing problems again,
particularly in connection with Philippe Lang's complaint here:
http://archives.postgresql.org/pgsql-general/2006-05/msg01526.php
Investigation showed that the planner is much too optimistic about the
usefulness of a multi-index BitmapA
David Fetter wrote:
On Wed, May 31, 2006 at 02:46:29PM -0400, Andrew Dunstan wrote:
I wish somebody would explain to me the compelling use case for
this.
As with "in-place upgrades,"[1] the compelling use case is being short
on disk space. For somebody with a multi-TB (or whatever fi
On Wed, May 31, 2006 at 02:46:29PM -0400, Andrew Dunstan wrote:
> I wish somebody would explain to me the compelling use case for
> this.
As with "in-place upgrades,"[1] the compelling use case is being short
on disk space. For somebody with a multi-TB (or whatever figure
sounds big this week) P
Andreas Pflug wrote:
Chris Browne wrote:
[EMAIL PROTECTED] (Andreas Pflug) writes:
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andreas
Pflug
Sent: 31 May 2006 16:41
Cc: Tom Lane; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS
Chris Browne wrote:
[EMAIL PROTECTED] (Andreas Pflug) writes:
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andreas
Pflug
Sent: 31 May 2006 16:41
Cc: Tom Lane; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Possible TODO item:
[EMAIL PROTECTED] (Andreas Pflug) writes:
> Dave Page wrote:
>>
>>>-Original Message-
>>> From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] On Behalf Of Andreas
>>> Pflug
>>>Sent: 31 May 2006 16:41
>>>Cc: Tom Lane; pgsql-hackers@postgresql.org
>>>Subject: Re: [HACKERS] Possible TODO ite
> >>>Won't help too much, until gzip's output is piped back too, so a
> >>>replacement for COPY .. TO STDOUT COMPRESSED would be
> COPY ... TO '|
> >>>/bin/gzip |' STDOUT, to enable clients to
> >>
> >>receive the
> >>
> >>>reduced stuff.
> >>
> >>Forgot to mention:
> >>COPY COMPRESSED was also
Joshua D. Drake wrote:
I dislike putting this into the backend precisely because it's trying to
impose a one-size-fits-all compression solution. Someone might wish to
use bzip2 instead of gzip, for instance, or tweak the compression level
options of gzip. It's trivial for the user to do that i
I dislike putting this into the backend precisely because it's trying to
impose a one-size-fits-all compression solution. Someone might wish to
use bzip2 instead of gzip, for instance, or tweak the compression level
options of gzip. It's trivial for the user to do that if the
compression progra
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Do you have a comment about the progress notification and its impact on
copy to stdout?
I didn't bother to comment on it because I think it's useless,
It's useful to see anything at all, and to be able to estimate how long
the whol
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andreas Pflug
Sent: 31 May 2006 16:41
Cc: Tom Lane; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Possible TODO item: copy to/from pipe
Andreas Pflug wrote:
Won't help too mu
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Forgot to mention:
> COPY COMPRESSED was also meant to introduce a portable format that's
> efficient for both text and binary data. Relying on some external XYZzip
> version seems not too portable to me.
I dislike putting this into the backend precise
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Do you have a comment about the progress notification and its impact on
> copy to stdout?
I didn't bother to comment on it because I think it's useless, as well
as broken for the stdout case. Anyone who actually sees a use for it
will have to comment o
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Pflug
> Sent: 31 May 2006 16:41
> Cc: Tom Lane; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Possible TODO item: copy to/from pipe
>
> Andreas Pflug wrote:
>
> >
> > Won't help to
Andreas Pflug wrote:
Won't help too much, until gzip's output is piped back too, so a
replacement for COPY .. TO STDOUT COMPRESSED would be
COPY ... TO '| /bin/gzip |' STDOUT, to enable clients to receive the
reduced stuff.
Forgot to mention:
COPY COMPRESSED was also meant to introduce a p
Tom Lane wrote:
After re-reading what I just wrote to Andreas about how compression of
COPY data would be better done outside the backend than inside, it
struck me that we are missing a feature that's fairly common in Unix
programs. Perhaps COPY ought to have the ability to pipe its output
to a
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
The attached patch implements COPY ... WITH [BINARY] COMPRESSION
(compression implies BINARY). The copy data uses bit 17 of the flag
field to identify compressed data.
I think this is a pretty horrid idea, because it changes pg_lzcom
On Wed, May 31, 2006 at 11:03:14AM -0400, Tom Lane wrote:
> After re-reading what I just wrote to Andreas about how compression
> of COPY data would be better done outside the backend than inside,
> it struck me that we are missing a feature that's fairly common in
> Unix programs. Perhaps COPY ou
Tom Lane wrote:
You can accomplish COPY piping now through psql, but it's a bit awkward:
psql -c "COPY mytable TO stdout" mydb | gzip ...
Thoughts? Is this worth doing, or is the psql -c approach good enough?
I think it's good enough. And there is also
pg_dump -F c -t b
Yannick wrote:
Bruce Momjian wrote:
It was applied 24-hours ago, and should be in CVS HEAD and the 8.1
stable branch.
I downloaded the source, following the instructions at
http://www.postgresql.org/developer/sourcecode/. It seems I didn't get
your commit :(
Log for win32.mak:
revision 1.36
d
After re-reading what I just wrote to Andreas about how compression of
COPY data would be better done outside the backend than inside, it
struck me that we are missing a feature that's fairly common in Unix
programs. Perhaps COPY ought to have the ability to pipe its output
to a shell command, or
Andreas Pflug <[EMAIL PROTECTED]> writes:
> The attached patch implements COPY ... WITH [BINARY] COMPRESSION
> (compression implies BINARY). The copy data uses bit 17 of the flag
> field to identify compressed data.
I think this is a pretty horrid idea, because it changes pg_lzcompress
from an u
Bruce Momjian wrote:
It was applied 24-hours ago, and should be in CVS HEAD and the 8.1
stable branch.
I downloaded the source, following the instructions at
http://www.postgresql.org/developer/sourcecode/. It seems I didn't get
your commit :(
Log for win32.mak:
revision 1.36
date: 2005/09/16
Martijn van Oosterhout writes:
> If you like I can send a patch that adds it to all of contrib and some
> of the other places required so that make check passes...
Think I got them all already:
http://archives.postgresql.org/pgsql-committers/2006-05/msg00384.php
but if you see any I missed...
I'm getting grudgingly more used to CVS HEAD's behavior of stuffing a
multiline command into the history buffer as a single item, but there's
still something bothering me about it. I've finally put my finger on
what. I think it should not combine SQL text and backslash commands
into a single hist
Hello Tom,
Thank you for the advice. I removed pqsignalinquire() method and it
worked just fine.
Stella Averbukh
_
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 30, 2006 11:29 AM
To: Averbukh Stella
Cc: pgsql-admin@p
I trid the following two queries in the version before your patch:
(1) which is reported in the bug("plan should not reference subplan's
variable") reported by Catalin Pitis:
INSERT INTO PROJECT(PROJECT_ID,PROJECT_DESC)(SELECT
MAX(PROJECT_ID),'MYPROJECT' FROM PROJECT WHERE NOT EXISTS (
SELECT
Magnus Hagander wrote:
> > > On Sun, May 07, 2006 at 08:21:43PM -0400, Tom Lane wrote:
> > >> I'm pretty sure we had agreed that magic blocks should be
> > required;
> > >> otherwise this check will accomplish little.
> >
> > > Sure, I just didn't want to break every module in one
> > weekend.
I've been playing around with COPYing large binary data, and implemented
a COMPRESSION transfer format. The server side compression saves
significant bandwidth, which may be the major limiting factor when large
amounts of data is involved (i.e. in many cases where COPY TO/FROM
STDIN/STDOUT is u
It was applied 24-hours ago, and should be in CVS HEAD and the 8.1
stable branch.
---
Jeff McKenna wrote:
> When is this patch going to be applied? Is there a bug that I can
> follow along?
>
> thanks.
>
> jeff
>
>
>
> > On Sun, May 07, 2006 at 08:21:43PM -0400, Tom Lane wrote:
> >> I'm pretty sure we had agreed that magic blocks should be
> required;
> >> otherwise this check will accomplish little.
>
> > Sure, I just didn't want to break every module in one
> weekend. I was
> > thinking of adding it with
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Christopher Kings-Lynne
> Sent: 31 May 2006 04:16
> To: Tom Lane
> Cc: Hackers
> Subject: Re: [HACKERS] PQescapeIdentifier
>
> > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> >> Here's a
On Tue, May 30, 2006 at 11:35:12AM -0400, Tom Lane wrote:
> FWIW, it looks like a large part of the bloat in the newer file is
> in-line documentation, which we hardly need to include in our
> distribution. I'll leave it to someone more familiar with Perl to
> determine whether we want to try to u
57 matches
Mail list logo
