> Since there are going to already be a number of fixes in beta2, I will
> wait until beta2 to release any RPM's. I am also continuing to get
> feedback about the packaging -- many thanks to all who are participating
> in that discussion! I remember the one or two comments I got on the 7.0
> RPM
Jean-Louis Leroy <[EMAIL PROTECTED]> writes:
> Both result sets seem wrong; even more bizarre, adding a column in the
> projection affects the result set.
> In addition, Tangram's test suite runs flawlessly against Sybase,
> Mysql, Oracle and Postgres 6.4.2.
Seems fishy, but there's not enough in
> We have merged README.mb into the official SGML docs, so the file is
> gone. Not sure what setup we have for SGML docs in different languages.
Even if the Big5 version of README.mb could be included in our SGML
docs, I don't think sgml tools could process Big5 without any problem
due to the na
I thought I saw mention on the interfaces list that the ODBC driver needed
to be modified to properly use the large objects.
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
http://www.rutgersinsurance.com
- Original Message -
From: "Frank Joerdens" <[EMAIL PROTECTED]>
To: "A
> I would set Seed per default. Even worse than a bad query path
> is an unpredictable query path. I see no argument, that a random Seed
> would buy us anything.
This kindof bugs me -- if you leave it stuck at a preset value, it makes it
possible to never delve into parts of solution space that
I agree, but I figured that if the 7.1 upgrade breaks some of the large
object interface in the ODBC code, it may possibly break some of the
interface in the php-psql code. That's why I said it should probably be
checked. ;)
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
http://ww
Hello,
While working on the next release of Tangram, I have encountered the
following problem in version 7.0.2. Given the following tables:
Springfield=> select version();
version
---
PostgreSQL 7.0.2 on i68
I'd say the most important thing would be to get it upto speed with 7.1.
Make sure PHP supports large objects and the TOAST properly.
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
http://www.rutgersinsurance.com
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]
I have been searching without luck on a howto on how to create locales for
postgres. Could somebody please point me in the general direction? Thanks.
:wq
Tim Uckun
Due Diligence Inc. http://www.diligence.com/ Americas Background
Investigation Expert.
If your company isn't doing background che
On 29 Dec 2000, Michael Alan Dorman wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > If there is something functionally wrong with Readline then let's talk
> > about it, but let's not replace it with something because some PHP dude
> > said that RMS said something.
>
> ncftp used to be
> * mlw <[EMAIL PROTECTED]> [001224 18:06] wrote:
> > This line works:
> > /usr/local/pgsql/bin/postmaster -N 32 -B 928 -i -S
> > -D/home/postgres/pgdev -o "-F -fs -S 4096"
> >
> > Where as this line:
> >
> > /usr/local/pgsql/bin/postmaster -N 32 -B 1024 -i -S
> > -D/home/postgres/pgdev -o "-F -fs
> But given that readline availability during the last five years was
> apparently just fine I don't understand this discussion at all.
I agree with Peter and others on this topic, though the occasional
discussion helps to clarify things...
- Thomas
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> If there is something functionally wrong with Readline then let's talk
> about it, but let's not replace it with something because some PHP dude
> said that RMS said something.
ncftp used to be for non-commercial use only and had hooks to be
linked a
> See bytea, though its presentation format leaves something to be desired IMHO
>
> > how would someone be expected to store, say, a GIF image in a TOAST text?
>
> One would not. A TOASTed bytea is the appropriate column type.
thanks -- that's EXACTLY what i needed.
On Fri, Dec 29, 2000 at 08:46:40PM -0500, Tom Lane wrote:
> Adam Haberlach <[EMAIL PROTECTED]> writes:
> > RMS already made a big stink about this, claiming that BeOS's use
> > of an emulation layer to link to some GPL'ed network drivers was enough
> > to force the GPL'ing of the kernel.
>
>
Adam Haberlach <[EMAIL PROTECTED]> writes:
> RMS already made a big stink about this, claiming that BeOS's use
> of an emulation layer to link to some GPL'ed network drivers was enough
> to force the GPL'ing of the kernel.
Did BeOS make distributions that included the GPL'd code?
Was the GP
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> If libedit could be used as an alternative to readline depending on your
> operating system setup then there's nothing wrong with that.
I have no objection to being able to work with either one, if someone's
excited about making that happen. I'd sti
On Sat, 30 Dec 2000, Peter Eisentraut wrote:
> The Hermit Hacker writes:
>
> > Actually, IMHO, the pro to moving to libedit is that we could include it
> > as part of the distribution and make history a *standard* feature
>
> History already is a standard feature, you just need to have readline
>
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> But given that readline availability during the last five years was
> apparently just fine I don't understand this discussion at all.
Indeed. You could make a better case that we shouldn't be including
in our distro the ODBC driver (LGPL) or the sev
The Hermit Hacker writes:
> Actually, IMHO, the pro to moving to libedit is that we could include it
> as part of the distribution and make history a *standard* feature
History already is a standard feature, you just need to have readline
installed. In a world of source code users need to cope
On Fri, 29 Dec 2000, Alfred Perlstein wrote:
> * The Hermit Hacker <[EMAIL PROTECTED]> [001229 17:06] wrote:
> > On Fri, 29 Dec 2000, Tom Lane wrote:
> >
> > > Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > > > My understanding (from the recent discussion) is that Postgresql
> > > > has certain
On Fri, Dec 29, 2000 at 07:15:05PM -0500, Tom Lane wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > Rasmus Lerdorf warned one of you guys that simply linking to GNU
> > readline can contaminate code with the GPL.
>
> > Readline isn't LGPL which permits linking without lincense issues,
>
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> someone brought up that when configure runs, it is adding -lreadline to
> the backend compile, even though that I don't think there is any reason
> for doing such?
There isn't --- configure is just sloppy in that it supplies the same
library list fo
On Fri, 29 Dec 2000, Tom Lane wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > My understanding (from the recent discussion) is that Postgresql
> > has certain dependancies on libreadline and won't compile/work
> > without it,
>
> Then you're working from a misconception.
I think the mi
* The Hermit Hacker <[EMAIL PROTECTED]> [001229 17:06] wrote:
> On Fri, 29 Dec 2000, Tom Lane wrote:
>
> > Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > > My understanding (from the recent discussion) is that Postgresql
> > > has certain dependancies on libreadline and won't compile/work
> > >
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> My understanding (from the recent discussion) is that Postgresql
> has certain dependancies on libreadline and won't compile/work
> without it,
Then you're working from a misconception.
regards, tom lane
* Tom Lane <[EMAIL PROTECTED]> [001229 16:38] wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > Actually, IMHO, the pro to moving to libedit is that we could include it
> > as part of the distribution and make history a *standard* feature
>
> How big is libedit? If it's tiny, that might
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> Could someone explain to me why not eliminating nulls destroys the
>> potential results of the query ? In other words, for any X not null, X
>> not in (some NULLs) is false.
> You already know the answer: comparisons to NULL always evaluate to
> fals
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> Rasmus Lerdorf warned one of you guys that simply linking to GNU
> readline can contaminate code with the GPL.
> Readline isn't LGPL which permits linking without lincense issues,
> it is GPL which means that if you link to it, you must be GPL as
> w
* Peter Eisentraut <[EMAIL PROTECTED]> [001229 16:01] wrote:
> The Hermit Hacker writes:
>
> > Is there a reason *not* to move towards that for v7.2 so that the
> > functions we are making optional with readline are automatic? Since we
> > could then ship the code, we could make it a standard vs
thelab# du -sk libedit
402 libedit
thelab# ls
Makefileel.hmap.c refresh.h tokenizer.c
TESTemacs.c map.h search.ctokenizer.h
chared.chist.c parse.c search.htty.c
chared.hhist.h
On Fri, 29 Dec 2000, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > How different is the feature set?
>
> I was going to ask the same thing. If it's an exact replacement then
> OK, but I do not want to put up with non-Emacs-compatible keybindings,
> to mention just one likely issu
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> Actually, IMHO, the pro to moving to libedit is that we could include it
> as part of the distribution and make history a *standard* feature
How big is libedit? If it's tiny, that might be a good argument ...
but I don't want to see us bulking up o
* Tom Lane <[EMAIL PROTECTED]> [001229 15:43] wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > How different is the feature set?
>
> I was going to ask the same thing. If it's an exact replacement then
> OK, but I do not want to put up with non-Emacs-compatible keybindings,
> to mention just
Paul A Vixie <[EMAIL PROTECTED]> writes:
> this is not what i was hoping for at ALL. evidently the implementation of
> text assumes NUL-termination in other places than the parser.
Yes. The entire datatype I/O system is based on null-terminated
strings, so there's no easy way to fix this. If i
Lamar Owen <[EMAIL PROTECTED]> writes:
> How different is the feature set?
I was going to ask the same thing. If it's an exact replacement then
OK, but I do not want to put up with non-Emacs-compatible keybindings,
to mention just one likely issue.
The whole thing really strikes me as make-work
The Hermit Hacker writes:
> Is there a reason *not* to move towards that for v7.2 so that the
> functions we are making optional with readline are automatic? Since we
> could then ship the code, we could make it a standard vs optional
> "feature" ...
>
> My thought would be to put 'make history
> Could someone explain to me why not eliminating nulls destroys the
> potential results of the query ? In other words, for any X not null, X
> not in (some NULLs) is false.
You already know the answer: comparisons to NULL always evaluate to
false. You may conclude that this exposes a flaw in SQL
On Sat, Dec 23, 2000 at 08:42:43AM -0800, Alfred Perlstein wrote:
>
> FreeBSD has a freely available library called 'libedit' that could
> be shipped with postgresql, it's under the BSD license.
>
> If you have access to a FreeBSD box see the editline(3) manpage,
> or go to:
>
>http://www.free
With this afternoon's CVS sources, I got a failure in the 'polygon'
regression test while running the parallel-mode tests:
--
CREATE TABLE POLYGON_TBL(f1 polygon);
+ ERROR: heap_update: (am)invalid tid
INSERT INTO POLYGON_TBL(f1) VALUES ('(2.0,0.0),(2.0,4.0),(0.0,0.0)');
(plus many subseq
for my pgcat utility i now know i have to use \nnn octal quoting for
nonprintables in the generated INSERT commands. but in testing, i
found the following oddity. this is in 7.1-b1 (cvs-current).
vixie=> create table foo ( bar text );
CREATE
vixie=> insert into foo value
Hey... I'm just learning how to do all this db stuff and I'm kinda
crippled because I've never used SQL.
Here is what I'm doing. I've got pgaccess working, it works greate, I
create databases and sql queries with it.
I've got JRun running for my servlet engine, it also works great.
Now when try
Hi !!
I'm using PostgreSQL 7.0.2 with Linux Mandrake 7.2, and not know as send
general data type or BLOB's to my win32 ODBC driver (PostODBC) from Visual
Fox Pro.
If yours have examples or source code of apps that sending/receive big
binaries data via ODBC, write me !!..
Help me friends !!
Sorry for intruding, but the following question did not get much
attention on the "General" list. However, I still need the answer ...
Could some kind soul explain this to me ?
test1=# select distinct "Cle" from "Utilisateurs";
Cle
-
1
2
3
4
(4 rows)
test1=# select distinct "CleUtil" f
Alfred Perlstein wrote:
>
> * The Hermit Hacker <[EMAIL PROTECTED]> [001229 14:11] wrote:
> > On Sat, 23 Dec 2000, Bruce Momjian wrote:
> >
> > > > FreeBSD has a freely available library called 'libedit' that could
> > > > be shipped with postgresql, it's under the BSD license.
> > >
> > > Yes, t
On Fri, 29 Dec 2000, Alfred Perlstein wrote:
> * The Hermit Hacker <[EMAIL PROTECTED]> [001229 14:11] wrote:
> > On Sat, 23 Dec 2000, Bruce Momjian wrote:
> >
> > > > FreeBSD has a freely available library called 'libedit' that could
> > > > be shipped with postgresql, it's under the BSD license
On Fri, 29 Dec 2000, The Hermit Hacker wrote:
> On Sat, 23 Dec 2000, Bruce Momjian wrote:
>
> > > FreeBSD has a freely available library called 'libedit' that could
> > > be shipped with postgresql, it's under the BSD license.
> >
> > Yes, that is our solution if we have a real problem here.
>
* The Hermit Hacker <[EMAIL PROTECTED]> [001229 14:11] wrote:
> On Sat, 23 Dec 2000, Bruce Momjian wrote:
>
> > > FreeBSD has a freely available library called 'libedit' that could
> > > be shipped with postgresql, it's under the BSD license.
> >
> > Yes, that is our solution if we have a real p
On Sat, 23 Dec 2000, Bruce Momjian wrote:
> > FreeBSD has a freely available library called 'libedit' that could
> > be shipped with postgresql, it's under the BSD license.
>
> Yes, that is our solution if we have a real problem here.
Is there a reason *not* to move towards that for v7.2 so tha
[EMAIL PROTECTED] writes:
> I compiled the 7.1 version of the snapshot dated on the December 18
> (on i386 Linux Red Hat 6.1). Using the notify in the rule actions I
> get some errors and I suppose they are bugs.
Thanks for the report and patch!
I don't like the unchecked assumption that get_ut
We backup our postgre 7.0.2 databases nightly via a cron script from a
remote box that calls pg_dump -f filename dbname or something to that
effect. About a week ago we started running out of disk space and we didn't
know it, and pg_dump doesn't report any errors so the cron script didn't
report
> > Actually, one slocks are held
> > longer than anothers - probably we should use different delays...
>
> I don't understand the last remark. Are you proposing to mix some
> random numbers into the delays?
No, use different s_spincycle-s for different slocks.
Vadim
On Fri, Dec 29, 2000 at 10:54:00AM -0800, Mikheev, Vadim wrote:
> > > The code is based on some odd assumptions. A select() with 0 delay
> > > returns immediately unless there is an interrupt during its
> > > (very short!) time in kernel space.
> >
> > Yeah, I've wondered whether the 0 entries
Hi!
I compiled the 7.1 version of the snapshot dated on the December 18 (on i386
Linux Red Hat 6.1).
Using the notify in the rule actions I get some errors and I suppose they are
bugs.
The first one when the rule is triggered:
[postgres@ postgres]$ createdb test
CREATE DATABASE
test=# crea
We have merged README.mb into the official SGML docs, so the file is
gone. Not sure what setup we have for SGML docs in different languages.
Sorry.
---
Tatsuo Ishii wrote:
> Here are the patches I promised against PHP
> > The code is based on some odd assumptions. A select() with 0 delay
> > returns immediately unless there is an interrupt during its
> > (very short!) time in kernel space.
>
> Yeah, I've wondered whether the 0 entries in s_spincycle[]
> shouldn't be 1. The code author evidently expected s
On Sun, 24 Dec 2000, Joe Conway wrote:
> Linux
>
> The default shared memory limit (both SHMMAX and SHMALL) is 32 MB in 2.2
> kernels, but it can be changed in the proc file system (without reboot). For
> example, to allow 128 MB:
>
> $ echo 134217728 >/proc/sys/kernel/shmall
> $ echo 134217
> Althoug this happens on old 6.5.3, I would like to know if this has
> been already fixed...
>
> Here is the scenario:
>
> 1) before vacuum, table A has 8850 tuples.
>
> 2) vacuum on table A makes postgres crashed.
>
> 3) it crashes at line 1758:
>
> Assert(num_moved == checked_moved);
58 matches
Mail list logo
