TODO updated:
* Allow TRUNCATE ... CASCADE/RESTRICT
---
Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > On Sun, 2003-08-17 at 00:42, Tom Lane wrote:
> >> To do anything else, you'd have to solve some
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Is anyone seriously suggesting that postgres should support either raw
> devices or use some sort of virtual file system? If not, this whole
> discussion is way off topic.
I have zero interest in actually doing it. However, it'd be nice if the
existi
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Well, if you want to be safer, I guess you could (at runtime) decide that
> the table's gotten too big and fall back to the old method if you didn't
> entirely rip it out. I'm not sure if that'd be too ugly though, but it
> would mean that you wouldn't h
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I had a private chat with Dave about this. It was my view that a missing
> file that is read by a backend COPY is indistinguishable from, say, a
> missing table or trigger, as far as recovery options by the client
> application are concerned.
Hm. On
Tom,
The reason it is of importance to me/ecpg is for informix compatibility.
informix returns a unique errorcode for the copy operation when the file
is not found. this isn't much of an argument from a postgres POV,
however I still find the sqlstate to be ambiguous.
Dave
On Sun, 2003-08-24 a
Tom Lane writes:
> Dave's correct, that's what we're currently using. I'm happy to change
> it if someone can suggest an appropriate SQLSTATE (even a category...)
> to use instead.
I had a private chat with Dave about this. It was my view that a missing
file that is read by a backend COPY is in
Since no one responded to the message below (posted on pgsql-sql), I made
the change from warning to error in the indicated cases.
> Fetching from a non-existent cursor:
>
> peter=# FETCH ALL FROM non_existent;
> WARNING: portal "non_existent" does not exist
> FETCH 0
>
> Closing a non-existent
Thomas,
[I would have responded sooner, but I have been on vacation.]
On Thu, Aug 21, 2003 at 11:10:05AM -0500, Thomas Swan wrote:
> On 8/8/2003 5:49 AM, Jason Tishler wrote:
> >Is this just the "--with-openssl" option? Does it build cleanly
> >under Cygwin? If so, would you like me to include
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Dave Cramer writes:
>> I'm working on identifying various errors in ecpg using sql state and
>> one which is particularly ambiguous is ERRCODE_UNDEFINED_OBJECT for a
>> file which isn't found. This is returned in a number of places. Is it
>> possible t
Greg Stark <[EMAIL PROTECTED]> writes:
> The glibc docs sample code suggests using 2x the original string
> length for the initial buffer. My testing showed that *always*
> triggered the exceptional case. A bit of experimentation lead to the
> 3x+4 which eliminates it except for 0 and 1 byte string
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Fri, 22 Aug 2003, Tom Lane wrote:
>> I'd go so far as to make it a critical section --- that ensures that any
>> ERROR will be turned to FATAL, even if it's in a subroutine you call.
> I didn't know we could do that, could be handy, although the comme
A row lock is represented by storing the locking transaction's ID in
xmax and setting the HEAP_MARKED_FOR_UPDATE infomask bit.
Where is 'xmax' found? is it at code level or on disk?
thanks
Jenny
From: Tom Lane <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: [HACKERS] t
following is taken from postgresql-7.3.2/src/backend/storage/lmgr/readme:
"If we are setting a table level lock
both the blockId and tupleId (in an item pointer this is called
the position) are set to invalid, if it is a page level lock the
blockId is valid, while the tuple
13 matches
Mail list logo
