Do any of you guys use linkedin.com and want to add me to your contacts
network?
Ironically, I don't use LinkedIn, even though they use PostgreSQL (not
exclusively, though).
Really? How do you know that? Are any of their people part of the
community?
Chris
On Tue, May 30, 2006 at 06:20:33PM -0400, Tom Lane wrote:
Now that the magic-block patch is in, we need to revisit this bit of the
discussion. I'm for making lack of a magic block an ERROR immediately.
I don't see the point of waiting; in fact, if we wait till freeze we'll
just make the
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 use
-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 question. I
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 LOG level
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
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
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 was
thinking
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
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
Martijn van Oosterhout kleptog@svana.org 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
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
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
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:
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
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
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
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 ought
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
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
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
-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 much,
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 on
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 precisely
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
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 whole
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
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
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 portable
[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: copy to/from pipe
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:
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)
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
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
*
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
reduced stuff.
Forgot to
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
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. Giving people
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]
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,
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 gzip pipe
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/to
Dave Page dpage@vale-housing.co.uk 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
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
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
On 31/5/06 21:10, Tom Lane [EMAIL PROTECTED] wrote:
Dave Page dpage@vale-housing.co.uk 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
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 not. It's GPL'd.
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
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
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.
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
windows.
Even then
[ moving this thread to -hackers ]
Martijn van Oosterhout kleptog@svana.org 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
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.
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 in
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
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
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 when
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
57 matches
Mail list logo
