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 try
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`, a
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
th
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 c
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 w
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
> com
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 broadcast)-
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 ou
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 (clauses.c:2320)
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 i
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 i
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
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 incli
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
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 a
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.
>
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 chi
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 b
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 versi
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 o
=?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
> http://groups
32 matches
Mail list logo
