[HACKERS] anoncvs troubles (was Re: CVS vs anoncvs)

2001-09-19 Thread Christof Petig
"Marc G. Fournier" wrote: > should be four hours, but I haven't had a chance, with the newest > worm/virus going around right now having killed our core router yesterday, > to redirect the sync'ag with the new server ... will do that first thing > tomorrow ... > > On Wed, 19 Sep 2001, Tom Lane wr

Re: [HACKERS] FOREIGN KEY taking write locks on parent.

2001-09-19 Thread Tom Lane
Rachit Siamwalla <[EMAIL PROTECTED]> writes: > I was just wondering, isn't the fact that FOREIGN KEY takes a write lock on > its parent a bug? Yes, I think so. Fixing it is not trivial (else we'd have done it right to start with) ... but if you want to step up to the plate to fix it, we're all e

Re: [HACKERS] type casting troubles

2001-09-19 Thread Thomas Lockhart
> > #2 0x806cb34 in TupleDescInitEntry (desc=0x82d6304, attributeNumber=1, > > attributeName=0x1f8 , oidtypeid=1184, > > typmod=-1, attdim=0, > > attisset=0 '\000') at tupdesc.c:365 > This appears to indicate that you have a Resdom node with an invalid > resname field. Seems like that wo

[HACKERS] FOREIGN KEY taking write locks on parent.

2001-09-19 Thread Rachit Siamwalla
I sent a message a while back on this list on why an insert onto a table A which has a foreign key constraint to table B obtains a write (exclusive) lock on that row on table B (basically does a select for update). The answer was there is no SQL construct to obtain read (shared) locks on a partic

Re: [HACKERS] Returning NULL from functions

2001-09-19 Thread Tom Lane
Thomas Lockhart <[EMAIL PROTECTED]> writes: > ERROR: OidFunctionCall3: function 1150 returned NULL > Is this error message a feature of all returns of NULL, particular to > input routines, or can I somehow mark routines as being allowed to > return NULL values? It's a "feature" for all places t

Re: [HACKERS] type casting troubles

2001-09-19 Thread Tom Lane
Thomas Lockhart <[EMAIL PROTECTED]> writes: > #2 0x806cb34 in TupleDescInitEntry (desc=0x82d6304, attributeNumber=1, > attributeName=0x1f8 , oidtypeid=1184, > typmod=-1, attdim=0, > attisset=0 '\000') at tupdesc.c:365 This appears to indicate that you have a Resdom node with an invalid

[HACKERS] Returning NULL from functions

2001-09-19 Thread Thomas Lockhart
I am working on date/time stuff, and in the spirit of cleaning up interesting but marginally useful features I've dropped support for "invalid" for the timestamp and timestamptz types. To help with upgrading, I thought that I'd map it to a NULL value, and see the following in the regression test

[HACKERS] type casting troubles

2001-09-19 Thread Thomas Lockhart
I have split the timestamp data type into two types to better match SQL9x specs. I've implemented them as "timestamp" and "timestamptz" (the latter corresponding to the implementation in recent releases), and have implemented conversion routines between the two types. However, I expect to be able

CVS vs anoncvs (was Re: [HACKERS] Case sensitive file names)

2001-09-19 Thread Tom Lane
Peter Bierman <[EMAIL PROTECTED]> writes: > If it's already been fixed (yay!), the fix isn't at anoncvs yet. I think there is some lag between the master CVS and anoncvs now. Marc, is that correct? How much lag? regards, tom lane ---(end of broad

Re: CVS vs anoncvs (was Re: [HACKERS] Case sensitive file names)

2001-09-19 Thread Marc G. Fournier
should be four hours, but I haven't had a chance, with the newest worm/virus going around right now having killed our core router yesterday, to redirect the sync'ag with the new server ... will do that first thing tomorrow ... On Wed, 19 Sep 2001, Tom Lane wrote: > Peter Bierman <[EMAIL PROTECT

[HACKERS] Status of greatbridge.org

2001-09-19 Thread Tom Lane
I am advised by the (few remaining) Great Bridge folk that they will be shutting down their webservers very shortly, like tomorrow. This will take the project pages at greatbridge.org offline. All the data at greatbridge.org has been transferred to a hub.org server at http://gborg.postgresql.org

Re: [HACKERS] Case sensitive file names

2001-09-19 Thread Peter Bierman
At 10:47 PM +0200 9/19/01, Peter Eisentraut wrote: >Peter Bierman writes: > >> While checking out TOT pgsql today onto an HFS+ file system (case-preserving, >case-insensitive), I hit the following CVS conflict: >> >> pgsql/src/backend/utils/mb/Unicode/utf8_to_alt.map >pgsql/src/backend/utils/mb/

Re: [HACKERS] Case sensitive file names

2001-09-19 Thread Peter Eisentraut
Peter Bierman writes: > At 10:47 PM +0200 9/19/01, Peter Eisentraut wrote: > >Peter Bierman writes: > > > >> While checking out TOT pgsql today onto an HFS+ file system (case-preserving, >case-insensitive), I hit the following CVS conflict: > >> > >> pgsql/src/backend/utils/mb/Unicode/utf8_to_al

Re: [HACKERS] Case sensitive file names

2001-09-19 Thread Serguei Mokhov
- Original Message - From: Peter Bierman <[EMAIL PROTECTED]> Sent: Wednesday, September 19, 2001 3:41 PM > While checking out TOT pgsql today onto an HFS+ file system (case-preserving, >case-insensitive), I hit the following CVS conflict: > > pgsql/src/backend/utils/mb/Unicode/utf8_to_al

Re: [HACKERS] Case sensitive file names

2001-09-19 Thread Peter Eisentraut
Peter Bierman writes: > While checking out TOT pgsql today onto an HFS+ file system (case-preserving, >case-insensitive), I hit the following CVS conflict: > > pgsql/src/backend/utils/mb/Unicode/utf8_to_alt.map >pgsql/src/backend/utils/mb/Unicode/utf8_to_ALT.map > > HFS+ can not store two diffe

[HACKERS] Case sensitive file names

2001-09-19 Thread Peter Bierman
While checking out TOT pgsql today onto an HFS+ file system (case-preserving, case-insensitive), I hit the following CVS conflict: pgsql/src/backend/utils/mb/Unicode/utf8_to_alt.map pgsql/src/backend/utils/mb/Unicode/utf8_to_ALT.map HFS+ can not store two differerent files in a path that diffe

Re: [HACKERS] Major change to CVS effective immediately ...

2001-09-19 Thread D'Arcy J.M. Cain
Thus spake Marc G. Fournier > can you ssh into cvs.postgresql.org? Yes! I could not do that before. Did you fix something? I will be sending some PyGreSQL changes over shortly. Thanks. -- D'Arcy J.M. Cain| Democracy is three wolves http://www.druid.net/darcy/| and a sh

Re: [HACKERS] Major change to CVS effective immediately ...

2001-09-19 Thread Patrick Welche
On Wed, Sep 19, 2001 at 10:14:44AM -0400, Marc G. Fournier wrote: > > :pserver:[EMAIL PROTECTED]:/projects/cvsroot While trying a cvs update, I get ? ChangeLogs/libecpg.so.3.1.1 ? ChangeLogs/HTML ? ChangeLogs/GTAGS ? ChangeLogs/GPATH ? ChangeLogs/GRTAGS ? ChangeLogs/GSYMS ? ChangeLogs/libpqpp.h

Re: [HACKERS] Major change to CVS effective immediately ...

2001-09-19 Thread Marc G. Fournier
:pserver:[EMAIL PROTECTED]:/projects/cvsroot On 18 Sep 2001, Gunnar [iso-8859-1] Rønning wrote: > * "Marc G. Fournier" <[EMAIL PROTECTED]> wrote: > | > | anoncvs.postgresql.org is going to be out of sync until, most likely, > | tomorrow, for anyone trying to use that ... anoncvs is *no longe

Re: [HACKERS] [Fwd: [Fwd: [tao-users] FW: HEADS UP: CVSup timestamp bug]]

2001-09-19 Thread Thomas Lockhart
> Right now, we have: OK, these are three *physically distinct* machines with some aliases attached to them? Or are virtual hosts involved too?? I need a site map from someone since nothing but my home directory is in the place they used to be (actually, even that moved but I *do* know how to fin

[HACKERS] CVSup Server has the time bug, needs to be upgraded

2001-09-19 Thread Otto Hirr
Please note that as of 07:24PST, 09-19 the cvsup server is old and needs to be upgraded, the following is what I now get when trying to sync: Parsing supfile "cvsup_config" Connecting to postgresql.org Connected to postgresql.org Server software version: REL_16_1 Server postgresql.org has the S1G

Re: [HACKERS] Major change to CVS effective immediately ...

2001-09-19 Thread Marc G. Fournier
can you ssh into cvs.postgresql.org? On Tue, 18 Sep 2001, D'Arcy J.M. Cain wrote: > Thus spake Marc G. Fournier > > This will most likely screw some ppl up, and fix others ... > > > > CVSROOT has now moved to the new machine, finally ... and I've cleaned up > > pathing ... and CVS_RSH=ssh now w

[HACKERS] Large object help requierd

2001-09-19 Thread Shridhar Daithankar
Hi, I am trying to store some large object in database. I print the number of bytes returned by lo_write. It's greater than zero. However sometime later, I start getting errors for lo_closelike invalid object descriptor fd=0 where df is variable I used for large object fd. Actually after lo_wr

Re: [HACKERS] Beta time

2001-09-19 Thread Tom Lane
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: >> 3. pfree'ing iname at the bottom doesn't strike me as a good >> idea; isn't that possibly part of your input querytree? > Hmmm. OK. What about in the case where iname is null and I give it a > makeObjectName? Don't worry about it. pallo

Re: [HACKERS] slow UNIONing

2001-09-19 Thread Peter Eisentraut
Kovacs Zoltan writes: > I experienced that UNIONs in 7.1.1 are rather slow: > > tir=# explain (select nev from cikk) union (select tevekenyseg from log); Try UNION ALL. Plain UNION will eliminate duplicates, so it becomes slower. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homei

[HACKERS] Where are the ERROR: Messages

2001-09-19 Thread Haller Christoph
[HACKERS] Where are the ERROR: Messages I'm converting from a C based program to PostgreSQL. There are some DBMS specific errors caught, i.e. deadlocks. Not only for this reason, but also from general curiosity I'd like to know what kinds of ERRORS PostgreSQL is dealing with. Which source c

Re: [HACKERS] Large objects and ecpg

2001-09-19 Thread Michael Meskes
On Wed, Sep 19, 2001 at 12:46:03AM +0530, Chamanya wrote: > Can I use ecpg with large objects? All examples in documentation are for > libpq. Yes and no. Since ECPG uses libpq it should not be too difficult to use the lo functions too. But there is no way to use them via some EXEC SQL statements

Re: [HACKERS] slow UNIONing

2001-09-19 Thread Zeugswetter Andreas SB SD
> I experienced that UNIONs in 7.1.1 are rather slow: > > tir=# explain (select nev from cikk) union (select > tevekenyseg from log); > NOTICE: QUERY PLAN: > > Unique (cost=667.63..687.18 rows=782 width=12) > -> Sort (cost=667.63..667.63 rows=7817 width=12) > -> Append (cost=0.