On Wednesday 25 June 2003 21:21, Jonathan Bartlett wrote:
My solution did not involve tablespaces, but was more of a quick solution
to make it easier for admins to do _some_ sort of physical configuration.
The idea is that the developer could do something like
'create alternate location
Hello:
Uhmmm, if you don't mind... are you implementing something like a data
provider for Postgresql, or it is just an ad hoc program?
Well i start making a simple library for 3.0 protocol for curiosity only
:), the protocol have a great documentation, but after some some days
i decide to
I tried readding the files now, I seems it got them now. Possibly cvs was
confused because those files already existed in the 7.3 branch so it
found dead revisions in the head branch.
Joe Conway writes:
Hmmm, I just updated to cvs tip (so I could try this), did `configure`,
`make clean`, and
On Wed, Jun 25, 2003 at 06:26:10PM +0900, [EMAIL PROTECTED] wrote:
ftp://ftp.kame.net/pub/kame/misc/
has IPv6 datatype patch (makes inet type handle both IPv4 and IPv6)
for 7.3.2. let me know how i can proceed/help.
There already is a patch in cvs head that does the same
Hi!
We have written two new files by name datacube.c in tcop directory
and datacube.h in include directory. We have even changed some
exsisting files. We have made a patch of the files that have been
changed.
But how should we send the new files datacube.c, and datacube.h along with
On 29 Jun 2003 at 19:25, Srikanth M wrote:
Please tell the procedure of submitting a new file along with the patch.
subscribe to patches list and send the patch there along with descriptions of
changes you have made.
HTH
Bye
Shridhar
--
COBOL: An exercise in Artificial Inelegance.
OK, worked out the wrinkle. psql is behaving perfectly well, but the shim
doesn't get a SIGPIPE until it tries to write to it after psql has exited.
A slightly hackish fix for this would be to put this line after the print
$_ line:
if ($_ eq \\q\n) { sleep 1; print ; } # get SIGPIPE if client
On Wed, Jun 25, 2003 at 14:05:10 +0200,
Brage [EMAIL PROTECTED] wrote:
A minor feature request:
PostgreSQL supports ISO-8601 week numbers with the syntax EXTRACT(WEEK FROM
timestamp) or TO_CHAR(timestamp,'IW'). There is, however, no easy way to
extract the year corresponding to the week
On Sun, Jun 29, 2003 at 10:22:49AM -0400, Andrew Dunstan wrote:
OK, worked out the wrinkle. psql is behaving perfectly well, but the shim
doesn't get a SIGPIPE until it tries to write to it after psql has exited.
A slightly hackish fix for this would be to put this line after the print
$_
I said:
While I now need to burrow into the IN-as-join code and find out where
it's dropping the ball, I don't think this need stop you from making
progress on the information schema. The reason the problem is appearing
seems to be the implied cast that's getting introduced in the IN
Carlos Guzman Alvarez wrote:
Hello:
Uhmmm, if you don't mind... are you implementing something like a data
provider for Postgresql, or it is just an ad hoc program?
Well i start making a simple library for 3.0 protocol for curiosity only
:), the protocol have a great documentation, but after
Peter Eisentraut wrote:
I tried readding the files now, I seems it got them now. Possibly cvs was
confused because those files already existed in the 7.3 branch so it
found dead revisions in the head branch.
Thanks, this fixed it for me.
Joe
---(end of
Hi all,
I'm getting the following error when trying to do an initdb:
This user must also own the server process.
The database cluster will be initialized with locale C.
Fixing permissions on existing directory /var/pgsqlcvs2... ok
creating directory /var/pgsqlcvs2/base... ok
creating directory
Francisco Figueiredo Jr. [EMAIL PROTECTED] writes:
initializing pg_depend... ERROR: expression_tree_walker: Unexpected
node type 601
IN: expression_tree_walker (clauses.c:2320)
Did you do a make clean and full recompile after your last cvs update?
This looks like some modules are out of
Francisco Figueiredo Jr. wrote:
Hi all,
I'm getting the following error when trying to do an initdb:
This user must also own the server process.
initializing pg_depend... ERROR: expression_tree_walker: Unexpected
node type 601
IN: expression_tree_walker (clauses.c:2320)
Hi Francisco,
I had
We don't need to read and write on the same fd.
The real right way is to detect when the psql client exits - possible when
the perl program spawns it, like shown below.
As always, TIMTOWTDI
andrew
--
use strict;
use IO::Handle;
use POSIX :sys_wait_h;
my $curpos;
my
Andreas Pflug wrote:
Francisco Figueiredo Jr. wrote:
Hi all,
I'm getting the following error when trying to do an initdb:
This user must also own the server process.
initializing pg_depend... ERROR: expression_tree_walker: Unexpected
node type 601
IN: expression_tree_walker
Hello:
That's very good!
Do you know about Npgsql?
Yes i know about it, but i have no see it in deep ( i use Firebird as
RDBMS at this moment ), i decide to take a glance at the 3.0 protocol
using C# when i know about the plans for a native Windows version in 7.4
version :) , but i'm not sure
Hello:
I'm trying to read an array, using binary format code and my own
implementation of the 3.0 protocol in C#, at this moment i have made
test with arrays of int2 and float4, seems that the server sends a
header of 24 bytes before the data in the buffer, i need to know what
these 24 bytes
On Sun, Jun 29, 2003 at 02:15:26PM -0400, Andrew Dunstan wrote:
We don't need to read and write on the same fd.
The real right way is to detect when the psql client exits - possible when
the perl program spawns it, like shown below.
As always, TIMTOWTDI
andrew
Carlos Guzman Alvarez [EMAIL PROTECTED] writes:
I'm trying to read an array, using binary format code and my own
implementation of the 3.0 protocol in C#, at this moment i have made
test with arrays of int2 and float4, seems that the server sends a
header of 24 bytes before the data in the
On Sun, Jun 22, 2003 at 09:01:35PM -0700, Sean Chittenden wrote:
As things stand, because O_DIRECT is an execution fast path through
the vfs subsystem, I expect the speed difference to be greater on
faster HDDs with high RPMs than on slower IDE machines at only
5400RPM... thus trivializing any
Tom Lane kirjutas E, 23.06.2003 kell 01:29:
Kevin Jacobs [EMAIL PROTECTED] writes:
Attached is a patch that removes all of the RExec code from plpython from
the current PostgreSQL CVS. In addition, plpython needs to be changed to an
untrusted language in createlang.
I am inclined to
Hannu Krosing [EMAIL PROTECTED] writes:
could we not just make sure that plpython uses python ver 2.x and use
plpythonu for python versions = 2.x until a secure regex solution comes
from Guido and folks ?
We'd still have to mark it untrusted, so what's the point?
Tom Lane kirjutas E, 30.06.2003 kell 00:18:
Hannu Krosing [EMAIL PROTECTED] writes:
could we not just make sure that plpython uses python ver 2.x and use
plpythonu for python versions = 2.x until a secure regex solution comes
from Guido and folks ?
We'd still have to mark it untrusted,
Hannu Krosing [EMAIL PROTECTED] writes:
The version with patch which removes RExec (as Python 2.x is not
supporting it ) is the right thoing to do FOR PYTHON 2.X, but there is
no reason to remove safe execution when using python 1.5.x.
Who's still using 1.5, I guess is the question? And are
Tom Lane kirjutas E, 30.06.2003 kell 01:21:
Hannu Krosing [EMAIL PROTECTED] writes:
The version with patch which removes RExec (as Python 2.x is not
supporting it ) is the right thoing to do FOR PYTHON 2.X, but there is
no reason to remove safe execution when using python 1.5.x.
Who's
On Sun, Jun 29, 2003 at 05:24:18PM -0400, Andrew Dunstan wrote:
- Original Message -
From: PeterKorman [EMAIL PROTECTED]
I like your solution. But I think I'd code it:
my $psqlpid = open(OUTPIPE,|-) || die qq(cant fork: $!);
Won't that cause the child to die because it
Hannu Krosing [EMAIL PROTECTED] writes:
Tom Lane kirjutas E, 30.06.2003 kell 01:21:
Who's still using 1.5, I guess is the question? And are they likely
to be updating their PG installation when they're not updating Python?
I guess that anyone who needs safe Restricted Execution will be using
Hannu Krosing wrote:
could we not just make sure that plpython uses python ver 2.x and use
plpythonu for python versions = 2.x until a secure regex solution comes
from Guido and folks ?
I guess most plpython users would be much happier with plpython with
some minor limitations due to older
Marc,
libpgtcl is already over at gborg, but pgtclsh is not:
http://gborg.postgresql.org/project/pgtcl/projdisplay.php
Karl Lehenbauer started the project, and I have helped
out along the way. Currently, my time is short, but I
probably would have time down the road to look into
moving pgtclsh
=?ISO-8859-1?Q?Gerhard_H=E4ring?= [EMAIL PROTECTED] writes:
... because most rexec problems are because
of the new-style classes in Python 2.2 and later, I asked on
comp.lang.python wether it was safe with 2.1 and earlier.
Martin von Löwis told me it probably wasn't in
32 matches
Mail list logo
