Note if you are trying to run more than one postgresql you also have to
prevent the unix socket files from clashing.
> On Wed, 27 Mar 2002, Alastair D'Silva wrote:
> >
> > > Is there any way to force PostgreSQL to bind to a specific
> > IP address?
> > >
> > > There doesn't seem to be anything
Sorry, we don't make a english translate yet. Sorry. It must be done soon.
Christopher Kings-Lynne wrote:
> This README file to me seems to look like this:
>
> Was the non-english version committed by mistake?
>
> Chris
>
>treequery *> tree[]
>
>
> true,
>
> ,
>
>
OOps,
I don't rememeber we have submitted this module :-)
I was intend to do that after writing README in English in 7.2 beta cycle,
but after decision it will not go to 7.2 I lost a focus.
Oleg
On Wed, 27 Mar 2002, Christopher Kings-Lynne wrote:
> This README file to me seems to look l
I just sent in this email and it will appear immediately in the list.
Somewhat earlier, I have submitted a 25kb patch and then a 5kb gzipped
version of that patch to -hackers and -patches - it has not yet appeared on
the list.
What's going on? Do posts with patches need to be approved or someth
This README file to me seems to look like this:
Was the non-english version committed by mistake?
Chris
treequery *> tree[]
true,
,
,
true,
,
.
GiST-.
1
select * from treetbl where treefld > '1.1' and treefld < '1.2';
selec
"Joel Burton" <[EMAIL PROTECTED]> writes:
>> This will allow you to run a single postgres in a single jail only one
>> user would have access to it. If you try to run more then one it will
>> try to use the same shared memory and crash.
> Is this, in fact, the case?
Unless BSD jails have very b
Stephan Szabo <[EMAIL PROTECTED]> writes:
> The advantage that I see is that we get more control over the time
> qualifications used for tuples which may come into play for match
> partial. I'm not sure that it's worth the effort to try doing it
> this way, but I figured I'd try it.
It might be
> You need to get your provider to set the sysctl jail.sysvipc_allowed to
> 1 in the host environment. If they're not willing to do this for you, we
> provide this feature on our servers, and also have a shared Postgres
> database you can use.
My ISP responds to this point:
"""
>In the thread on
On Tue, 26 Mar 2002, Jan Wieck wrote:
> Tom Lane wrote:
> > I think the existing scheme of generating the plan during first use
> > in a particular backend is fine. At least as long as we're sticking
> > with standard plans at all ... IIRC Stephan was wondering about
> > bypassing the whole par
"Nicolas Bazin" <[EMAIL PROTECTED]> writes:
> It's more warnings than bugs. I also have seen that but not familiar enough
> with bison or yacc to think more of it. Have you got an idea on how to fix
> these warnings?
ecpg's lexer has always generated those warnings, and so has plpgsql's
lexer. A
Christopher Kings-Lynne wrote:
> I don't think this is me...
>
> gcc -pipe -O -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-error -I
> ./../include -I. -I../../../../src/include -DMAJOR_VERSION=2 -DMINOR_VERSIO
> N=10 -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/home/chriskl/local/include\" -c -o
- Original Message -
From: Nicolas
Bazin
To: [EMAIL PROTECTED]
Sent: Wednesday, March 27, 2002 4:03 PM
Subject: pgc.l modif. has been overwritten again
We need a little bit of order when several people
can commit on the source code, It would be nice that they update their local
It's more warnings than bugs. I also have seen that but not familiar enough
with bison or yacc to think more of it. Have you got an idea on how to fix
these warnings?
- Original Message -
From: "Christopher Kings-Lynne" <[EMAIL PROTECTED]>
To: "Hackers" <[EMAIL PROTECTED]>
Sent: Wednesday,
I don't think this is me...
gcc -pipe -O -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-error -I
./../include -I. -I../../../../src/include -DMAJOR_VERSION=2 -DMINOR_VERSIO
N=10 -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/home/chriskl/local/include\" -c -o
pgc.o pgc.c
pgc.c: In function `yylex':
> > Tom Lane wrote:
> >> An advantage of using OIDs is that we could forget the pushups that
> >> ALTER TABLE RENAME presently goes through to update RI triggers.
>
> > I'm always suspicious about the spec if it makes RENAME easy.
>
> Point taken ;-)
I don't get it???
Chris
-
Cheers, next time I'll look a bit harder :)
--
Alastair D'Silva B. Sc.mob: 0413 485 733
Networking Consultant
New Millennium Networking http://www.newmillennium.net.au
> -Original Message-
> From: Gavin Sherry [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 27 March 2002 3:4
On Wed, 27 Mar 2002, Alastair D'Silva wrote:
> Is there any way to force PostgreSQL to bind to a specific IP address?
>
> There doesn't seem to be anything about this in the docs, and if its not
> implemented, it would be a useful feature to have (and an easy one to
> implement).
(from runtime-c
Is there any way to force PostgreSQL to bind to a specific IP address?
There doesn't seem to be anything about this in the docs, and if its not
implemented, it would be a useful feature to have (and an easy one to
implement).
--
Alastair D'Silva B. Sc.mob: 0413 485 733
Networking Con
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> An advantage of using OIDs is that we could forget the pushups that
>> ALTER TABLE RENAME presently goes through to update RI triggers.
> I'm always suspicious about the spec if it makes RENAME easy.
Point taken ;-)
However, unless
> -Original Message-
> From: Alastair D'Silva [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 26, 2002 10:52 PM
> To: 'Vince Vielhaber'; 'Joel Burton'
> Cc: [EMAIL PROTECTED]
> Subject: RE: [HACKERS] initdb dies during IpcSemaphoreCreate under BSD
> jail
>
>
> You need to get your provid
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > I can do it hear easily. Let me know and I will give you the URL. It
> > takes only 7 minutes here.
>
> Go ahead. Just make sure you use some reasonably recent style sheets (>=
> 1.70) and not 1.64 that you currently have.
I will not be a
You need to get your provider to set the sysctl jail.sysvipc_allowed to
1 in the host environment. If they're not willing to do this for you, we
provide this feature on our servers, and also have a shared Postgres
database you can use.
--
Alastair D'Silva B. Sc.mob: 0413 485 733
Netwo
Tom Lane wrote:
>
> As of CVS tip, referential integrity triggers are kinda broken: they
> will only work for tablenames that are in the current search path.
> I think that instead of storing just table names in the trigger
> parameters, we should store either table OIDs or schema name + table
> n
Bruce Momjian writes:
> I can do it hear easily. Let me know and I will give you the URL. It
> takes only 7 minutes here.
Go ahead. Just make sure you use some reasonably recent style sheets (>=
1.70) and not 1.64 that you currently have.
--
Peter Eisentraut [EMAIL PROTECTED]
--
El Mar 26, Peter Eisentraut escribio:
> Marc G. Fournier writes:
> > should there be a step in the 'build dist'
> > that builds the docs based on the sgml?
>
> I've been promoting that every time this problem happens. And the problem
> does happen every time we're making a minor release. I thi
Peter Eisentraut wrote:
> Marc G. Fournier writes:
>
> > good point ... but, where should I be pulling from? ~ftp/pub/doc/7.2
> > contains .pdf files, which I didn't think we wanted to put into the
> > distribution ... is there an alternative place I should be pulling docs
> > >from then ~ftp/pu
Marc G. Fournier writes:
> good point ... but, where should I be pulling from? ~ftp/pub/doc/7.2
> contains .pdf files, which I didn't think we wanted to put into the
> distribution ... is there an alternative place I should be pulling docs
> >from then ~ftp/pub/dev/doc?
No, there currently is n
There's no such thing as stable ports - there is only HEAD...
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Eisentraut
> Sent: Wednesday, 27 March 2002 2:14 AM
> To: Marc G. Fournier
> Cc: PostgreSQL Development
> Subject: Re: [HACKER
Bruce,
The reason to move the socket library is that during configuration script
execution, the binary created core dumps if not in the order I gave. You can
check in the port list, some people have been complaining that they could
not even go any further than the configure step and that is the r
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Actually I'm kicking around a slightly different idea, how to
> > resolve the entire problem. We could build up the
> > querystring, required to do the check, at trigger creation
> > time, parse it and stor
Jan Wieck <[EMAIL PROTECTED]> writes:
> Actually I'm kicking around a slightly different idea, how to
> resolve the entire problem. We could build up the
> querystring, required to do the check, at trigger creation
> time, parse it and store the querytree node-print
On Tue, 26 Mar 2002, Tom Lane wrote:
> As of CVS tip, referential integrity triggers are kinda broken: they
> will only work for tablenames that are in the current search path.
> I think that instead of storing just table names in the trigger
> parameters, we should store either table OIDs or sch
Tom Lane wrote:
> As of CVS tip, referential integrity triggers are kinda broken: they
> will only work for tablenames that are in the current search path.
> I think that instead of storing just table names in the trigger
> parameters, we should store either table OIDs or schema name + table
> nam
I'm trying to work out what to do with indexes in the context of
schemas.
As of today's CVS tip, what the code does is that CREATE INDEX can only
specify an unqualified index name, and the index is automatically
created in the same namespace as its parent table. Thus, index names
still have to b
As of CVS tip, referential integrity triggers are kinda broken: they
will only work for tablenames that are in the current search path.
I think that instead of storing just table names in the trigger
parameters, we should store either table OIDs or schema name + table
name. Do you have any prefer
On Tue, 26 Mar 2002 13:13:58 -0500 (EST)
Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Marc G. Fournier writes:
>
> > %autoconf --version
> > autoconf (GNU Autoconf) 2.52
>
> FreeBSD HEAD has 2.53 in ports. Not sure if you can pull that in if
> you're following stable.
>
> --
> Peter Eisentr
Easily, just pointing out that we are already at 2.52 on the main server
... just upgraded it on the 12th, will work on upgrading it over the next
day or so, since I'm in the middle of dealing with preparations for a
security audit at the University *oh joy* ... :)
On Tue, 26 Mar 2002, Peter Ei
Marc G. Fournier writes:
> %autoconf --version
> autoconf (GNU Autoconf) 2.52
FreeBSD HEAD has 2.53 in ports. Not sure if you can pull that in if
you're following stable.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3:
%autoconf --version
autoconf (GNU Autoconf) 2.52
Written by David J. MacKenzie.
Copyright 1992, 1993, 1994, 1996, 1999, 2000, 2001
Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PA
Thomas Lockhart writes:
> Did you catch the questions on dealing with HAVE_LONG_INT_64,
> HAVE_LONG_LONG_INT_64, and INT64_IS_BUSTED? I'd like to be able to
> enable/disable integer date/time storage in configure, so some notion of
> "do I have some kind of 64 bit integer?" seems to be desirable
> I plan to upgrade to Autoconf 2.53 in the next couple of days. If anyone
> has configure changes pending or other objections, speak now.
I'm working on the integer timestamp issue, which seems to have an
autoconf component. I was hoping for feedback on the question of setting
HAVE_LONG_INT_64,
I plan to upgrade to Autoconf 2.53 in the next couple of days. If anyone
has configure changes pending or other objections, speak now.
An RPM package for Autoconf 2.53 is available at
http://www.postgresql.org/~petere/download/
You might wish to use this until your vendor comes out with one.
Hi Justin,
I have a new updated version of the Ora2Pg tool which correct many
problems and add some new features, could you or someone else update
the contrib directory.
(download at: http://www.samse.fr/GPL/ora2pg/ora2pg-1.8.tar.gz)
I also just post a new tool in replacement of the Oracle XSQL
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> should there be a step in the 'build dist'
> that builds the docs based on the sgml?
It would be a good idea to rebuild the 7.2 docs from 7.2.1 sources,
as we made several important fixes in the documentation since 7.2
release. I dunno whether it'
good point ... but, where should I be pulling from? ~ftp/pub/doc/7.2
contains .pdf files, which I didn't think we wanted to put into the
distribution ... is there an alternative place I should be pulling docs
from then ~ftp/pub/dev/doc? should there be a step in the 'build dist'
that builds the
We am going to need an explaination on these changes. Why move
the socket test? Why change pow()? The TCL stuff is going to
effect other platforms and probably will not be applied without a
good reason.
---
Nicolas Bazin
46 matches
Mail list logo
