"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
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
> > #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
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
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
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
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
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
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
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
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
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/
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
- 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
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
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
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
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
: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
> 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
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
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
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
"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
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
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
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
> 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.
28 matches
Mail list logo