Am Montag, 11. Oktober 2004 22:31 schrieb Tom Lane:
> The problem of course is that we have no rpath pointing to the place
> where libperl.so lives. (Now that I look, the only reason this worked
> before was that I had /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE
> mentioned in /etc/ld.so.con
On Mon, 11 Oct 2004, Marc G. Fournier wrote:
Also, the link to cvsweb interface at http://developer.postgresql.org/
broke.
How so? I just wwent to the link and everything appears fine to me ...
There's a link to "PostgreSQL Server CVS web interface" in the bottom of
that page, which still points
On Tue, 2004-10-12 at 09:40, Tom Lane wrote:
> Copy-and-paste oversight I'd say. Probably the latter ought to be
> "PortalHoldContext" or some such.
Thanks, that's what I suspected. I've applied the attached fix to HEAD.
-Neil
Index: src/backend/utils/mmgr/portalmem.c
==
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Mon, 11 Oct 2004, Heikki Linnakangas wrote:
>> Also, the link to cvsweb interface at http://developer.postgresql.org/
>> broke.
> How so? I just wwent to the link and everything appears fine to me
Down at the bottom of http://developer.postgre
Neil Conway <[EMAIL PROTECTED]> writes:
> On Tue, 2004-10-12 at 05:08, Greg Stark wrote:
>> You wouldn't be able to find errors in the semantics of xids for example, or
>> in the WAL logic that didn't cover some corner case. Or race conditions
>> between backends...
> Going into this, these were p
Greg Stark wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > OK, I have applied the following patch that uses Cygwin native symlink()
> > instead of the Win32 junctions. The reason for this is that Cygwin
> > symlinks work on Win95/98/ME where junction points do not
>
> Is this really a
On Tue, 12 Oct 2004, Neil Conway wrote:
> On Tue, 2004-10-12 at 05:08, Greg Stark wrote:
> > But it seems to me that most of the really hard bugs to find involve subtle
> > interactions between functions and the state of the database.
> >
> > You wouldn't be able to find errors in the semantics of
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, I have applied the following patch that uses Cygwin native symlink()
> instead of the Win32 junctions. The reason for this is that Cygwin
> symlinks work on Win95/98/ME where junction points do not
Is this really a Win95/98/ME vs NT distinction or
On Mon, 11 Oct 2004, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > On Tue, 2004-10-12 at 00:43, Tom Lane wrote:
> >> Most likely (and I for one will for sure resist any attempt to force
> >> global uniqueness on static names).
>
> > You're right that the issue can be avoided easily
On Mon, 11 Oct 2004, Heikki Linnakangas wrote:
On Sun, 10 Oct 2004, Marc G. Fournier wrote:
pgsql-server renamed to pgsql
contrib/earthdistance moved back into pgsql/contrib/earthdistance
modules file updated for changes
checkout seems to work fine for me ... let me know if there are any
problems
Neil Conway <[EMAIL PROTECTED]> writes:
> On Tue, 2004-10-12 at 00:43, Tom Lane wrote:
>> Most likely (and I for one will for sure resist any attempt to force
>> global uniqueness on static names).
> You're right that the issue can be avoided easily enough, but what need
> is there _not_ to have g
On Tue, 2004-10-12 at 05:08, Greg Stark wrote:
> But it seems to me that most of the really hard bugs to find involve subtle
> interactions between functions and the state of the database.
>
> You wouldn't be able to find errors in the semantics of xids for example, or
> in the WAL logic that didn
On Tue, 2004-10-12 at 00:43, Tom Lane wrote:
> Most likely (and I for one will for sure resist any attempt to force
> global uniqueness on static names).
You're right that the issue can be avoided easily enough, but what need
is there _not_ to have globally unique function names?
-Neil
---
Bruce Momjian schrieb:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
OK, I have applied the following patch that uses Cygwin native symlink()
instead of the Win32 junctions. The reason for this is that Cygwin
symlinks work on Win95/98/ME where junction points do not and we have no
way
Neil Conway <[EMAIL PROTECTED]> writes:
> The memory context created at src/backend/utils/mmgr/portalmem.c:183
> shares the name of the memory context created at portalmem.c:279 (they
> are both called "PortalHeapMemory"). Is there a reason for this?
Copy-and-paste oversight I'd say. Probably the
Bruce Momjian schrieb:
I am curious why Cygwin needs DLLINIT in Makefile.shlib, and Win32
doesn't:
# Cygwin case
$(shlib) lib$(NAME).a: $(OBJS) $(DLLINIT)
$(DLLTOOL) --export-all $(DLLTOOL_DEFFLAGS) --output-def $(NAME).def
$(OBJS)
$(DLLWRAP) -o $(sh
The memory context created at src/backend/utils/mmgr/portalmem.c:183
shares the name of the memory context created at portalmem.c:279 (they
are both called "PortalHeapMemory"). Is there a reason for this?
-Neil
---(end of broadcast)---
TIP 5: Have
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, I have applied the following patch that uses Cygwin native symlink()
> > instead of the Win32 junctions. The reason for this is that Cygwin
> > symlinks work on Win95/98/ME where junction points do not and we have no
> > way to kn
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, I have applied the following patch that uses Cygwin native symlink()
> instead of the Win32 junctions. The reason for this is that Cygwin
> symlinks work on Win95/98/ME where junction points do not and we have no
> way to know what system will be run
OK, I have applied the following patch that uses Cygwin native symlink()
instead of the Win32 junctions. The reason for this is that Cygwin
symlinks work on Win95/98/ME where junction points do not and we have no
way to know what system will be running the Cygwin binaries so the
safest bet is to
I am curious why Cygwin needs DLLINIT in Makefile.shlib, and Win32
doesn't:
# Cygwin case
$(shlib) lib$(NAME).a: $(OBJS) $(DLLINIT)
$(DLLTOOL) --export-all $(DLLTOOL_DEFFLAGS) --output-def $(NAME).def
$(OBJS)
$(DLLWRAP) -o $(shlib) --dllname $(shlib
On Tue, 2004-10-05 at 05:09, Dave Page wrote:
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Ian FREISLICH
> > Sent: 05 October 2004 09:57
> > To: Greg Sabino Mullane
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [HACKERS] PL/PgSQL for cou
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
On my FC3 installation, there is a /usr/lib/libpython2.3.so.1.0
... do you have anything comparable?
No, except the non-standard one on the openoffice libs. Building as shared
lib only became a part of standard python in rel
I've just noticed that plperl is broken on my new Fedora installation:
[EMAIL PROTECTED] plperl]$ make
...
gcc -O2 -fno-strict-aliasing -g -fpic -shared -Wl,-soname,libplperl.so.0 plperl.o
spi_internal.o SPI.o -L../../../src/port -L/usr/local/lib
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/auto
Dan Libby <[EMAIL PROTECTED]> writes:
> I am still curious to hear an estimate of the difficulty of adding
> rowset vars representing OLDSET and NEWSET to each trigger defined as
> 'FOR EACH STATEMENT'.
It's on the TODO list, but I don't think anyone has a clear fix on the
implementation effort
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>> On my FC3 installation, there is a /usr/lib/libpython2.3.so.1.0
>> ... do you have anything comparable?
> No, except the non-standard one on the openoffice libs. Building as shared
> lib only became a part of standard python in release 2.3 - see
> ht
Neil Conway <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
> > 2. Won't dissolving away "static" cause naming conflicts?
>
> It might, yes. Those can be resolved, I think. I don't see a good reason why
> function names can't be unique across the source tree; at the very least, it
> means les
On Sun, 10 Oct 2004, Marc G. Fournier wrote:
pgsql-server renamed to pgsql
contrib/earthdistance moved back into pgsql/contrib/earthdistance
modules file updated for changes
checkout seems to work fine for me ... let me know if there are any problems
"cvs update" stopped working for me, I guess I'l
Neil Conway wrote:
3. Unit testing frameworks are best suited to component-based
architectures, ISTM. I'm not sure that one would fit Postgres very well.
Can you elaborate?
With objects that are relatively standalone, you can instantiate them
easily and plug them into a testing framework. The
John Bercik <[EMAIL PROTECTED]> writes:
> I'm in PG 8.0b3 and in it's psql i perform an -Fc pg_dump on a 7.4 db.
> When I go to restore in PG 8.0b3 I get errors because of schemas that
> have capital letters ("EMRImporting"). It creates schema "emrimporting"
> and fails upon trying to restore
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> 2. Won't dissolving away "static" cause naming conflicts?
Most likely (and I for one will for sure resist any attempt to force
global uniqueness on static names). It seems that that whole issue
is easily avoided though ... just #include the source file
Andrew Dunstan wrote:
2. Won't dissolving away "static" cause naming conflicts?
It might, yes. Those can be resolved, I think. I don't see a good reason
why function names can't be unique across the source tree; at the very
least, it means less irritation for anyone using tags.
3. Unit testing f
Greg Stark schrieb:
Christopher Browne <[EMAIL PROTECTED]> writes:
- The alternative _I_ would most like would be to deploy web apps
in Lisp, but I never have the "round tuits" to get into that
very far...
If you find any tuits sometime you might want to check out Per Bothner's Kawa.
It's a schem
Neil Conway wrote:
[ apologies if this mail is poorly formatted, posted via webmail ]
Gavin Sherry said:
For the latest few weeks Neil and I have been discussing unit testing as
a means of testing Postgres more rigorously.
I should note that we've also been looking at some other ideas, inc
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Mon, 11 Oct 2004, Tom Lane wrote:
>> "numeric", hm? Is the referenced column also of type numeric?
> Correct, and a join of the two tables appears to use both indices, altho
> one is of numeric(9,0) and the other numeric(12,0) ... could that
>
[ apologies if this mail is poorly formatted, posted via webmail ]
Gavin Sherry said:
> For the latest few weeks Neil and I have been discussing unit testing as
> a means of testing Postgres more rigorously.
I should note that we've also been looking at some other ideas, including
different appro
I'm in PG 8.0b3 and in it's psql i perform an -Fc pg_dump on a 7.4 db.
When I go to restore in PG 8.0b3 I get errors because of schemas that
have capital letters ("EMRImporting"). It creates schema "emrimporting"
and fails upon trying to restore data to "EMRImporting" schema because
it doesn'
Hi guys,
For the latest few weeks Neil and I have been discussing unit testing as
a means of testing Postgres more rigorously. A brief overview of the ideas
behind unit testing can be found here:
http://www.extremeprogramming.org/rules/unittests.html.
The basic idea is that you write small(ish) t
>> On Fri, 08 Oct 2004 00:26:06 -0400, Tom Lane <[EMAIL PROTECTED]> said:
> Shinji Teragaito <[EMAIL PROTECTED]> writes:
> 152c152
> < SHLIB_LINK += `$(CC) -print-libgcc-file-name`
> ---
>> SHLIB_LINK += `$(CC) $(LDFLAGS) -print-libgcc-file-name`
> Okay. I'm slightly w
39 matches
Mail list logo
