On Thu, 2002-07-04 at 11:45, J. R. Nield wrote:
One other item that should be here:
> The big items so-far are:
> §1 - Logging Relation file creation, truncation, and removal
> This is mostly done. Can do infinte play-forward from
> online logs.
> §2 -
Rod Taylor <[EMAIL PROTECTED]> writes:
> I think it would be a rare event to have more than one person changing
> the database structure at the same time.
I don't buy this assumption --- consider for example two clients
creating temp tables.
> Anyway, the index example is a
> bad example isn't i
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Largely-illusory? Almost every pg_attribute query will have to be modified
> for isdropped, while Hiroshi's approach requires so few changes, we are
> having trouble even finding a query that needs to be modified. That's
> pretty clear to me.
Apparent
Hello:
I've got the logging system to the point where I can take a shutdown
consistent copy of a system, and play forward through multiple
checkpoints. It seems to handle CREATE TABLE/DROP TABLE/TRUNCATE
properly, and things are moving forward well. Recovery to an arbitrary
point-in-time should b
I've committed support for IS DISTINCT FROM to the head of the CVS tree.
I did not update the catalog version, but since one enumerated type has
added a value it may be that initdb is actually required. Almost
certainly a "make clean" is essential.
There is more work to do, including perhaps addi
On Thu, Jul 04, 2002 at 10:00:01AM +0800, Raymond Fung wrote:
> Dear all,
> ...
> It has translated the 4 bytes constant (0x87654321) into a one byte
> char constant (within the single quotes) during pre-processing. Seems
> this happens only when the high bit of the constant is set (i.e. it
> won'
Thomas Lockhart wrote:
> > Well in the renumbering case, the client needs to know about missing attnos
> > and it has to know to ignore negative attnos (which it probably does
> > already). ie. psql and pg_dump wouldn't have to be modified in that case.
> > In the isdropped case, the client needs
> > and not simply a lock on the pg_constraint table
>
> In this context, a lock on pg_constraint *is* global, because it will
> mean that no one else can be creating an index on some other table.
> They'd need to hold that same lock to ensure that *their* chosen
> constraint name is unique.
So
Dear all,
A simple testing program :
* * * * * * * * * * * * * * begin * * * * * * * * * * * * * * * *
#include
#include
int main (void)
{
unsigned int v;
v = 0x87654321L;
return (0);
}
* * * * * * * * * * * * * * end * * * * * * * * * * * * * * * *
compile with ecpg using :
> BTW there seems a misunderstanding about my posting.
> I'm not objecting to add attisdropped pg_attribute column.
> They are essentially the same and so I used macros
> like COLUMN_IS_DROPPED in my implementation so that
> I can easily change the implementation to use isdropped
> pg_attribute col
Tom Lane wrote:
>
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > OK, I've been looking at Hiroshi's implementation. It's basically
> > semantically equivalent to mine from what I can see so far. The only
> > difference really is in how the dropped columns are marked.
>
> True enoug
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: 04 July 2002 07:40
> To: Tom Lane
> Cc: Christopher Kings-Lynne; Hiroshi Inoue; Hackers
> Subject: Re: [HACKERS] BETWEEN Node & DROP COLUMN
>
>
> Well, why shouldn't we use the fact that most/all clients
>
> My problem is that you are pushing the DROP COLUMN check out into almost
> every client that uses pg_attribute. And we are doing this to keep our
> backend cleaner. Seems we should do the work once, in the backend, and
> not burden clients will all of this.
As a user of Postgres, I found the
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Actually, your trial required column dropped-ness to be checked in
> >> many more places than the proposed approach does.
>
> > Have you ever really checked my trial implementation ?
>
> Well, I've certainly s
> > No, he only breaks even for client cleanliness --- either approach
> > *will* require changes in clients that look at pg_attribute.
>
> Uh, Christopher already indicated three clients, psql, pg_dump, and
> another that will not require changes for Hiroshi's approach, but will
> require change
Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > OK, I've been looking at Hiroshi's implementation. It's basically
> > semantically equivalent to mine from what I can see so far. The only
> > difference really is in how the dropped columns are marked.
>
> True enough,
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> What happens if someone drops ALL the columns in a table?
Good point. Ideally we should allow that, but in practice I suspect
there are many places that will blow up on zero-length tuples.
Rejecting the situation might be the better part of
> True enough, but that's not a trivial difference. The problem with
> Hiroshi's implementation is that there's no longer a close tie between
> pg_attribute.attnum and physical positions of datums in tuples. I think
> that that's going to affect a lot of low-level code, and that he hasn't
> foun
By the way,
What happens if someone drops ALL the columns in a table? Do you just leave
it there as-is without any columns or should it be forbidden or should it be
interpreted as a drop table?
Chris
---(end of broadcast)---
TIP 1: subscribe a
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Well, it seems isdropped is going to have to be checked by _any_ client,
> > while holes in the number will have to be checked by _some_ clients. Is
> > that accurate?
>
> What's your point? No client that examines pg_attribute can
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> OK, I've been looking at Hiroshi's implementation. It's basically
> semantically equivalent to mine from what I can see so far. The only
> difference really is in how the dropped columns are marked.
True enough, but that's not a trivial di
> > What's your point? No client that examines pg_attribute can be trusted
> > until it's been examined pretty closely (as in, more closely than
> > Christopher looked at pg_dump). I'd prefer to see us keep the backend
> > simple and trustworthy, rather than pursue a largely-illusory idea that
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Well, it seems isdropped is going to have to be checked by _any_ client,
> while holes in the number will have to be checked by _some_ clients. Is
> that accurate?
What's your point? No client that examines pg_attribute can be trusted
until it's been
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Well, it seems isdropped is going to have to be checked by _any_ client,
> > while holes in the number will have to be checked by _some_ clients. Is
> > that accurate?
>
> What's your point? No client that examines pg_attribute can
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Actually, your trial required column dropped-ness to be checked in
>> many more places than the proposed approach does.
> Have you ever really checked my trial implementation ?
Well, I've certainly stumbled over it in places like rel
Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Actually, your trial required column dropped-ness to be checked in
> >> many more places than the proposed approach does.
>
> > Have you ever really checked my trial implementation ?
>
> Well, I've certainly stu
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> No, he only breaks even for client cleanliness --- either approach
> >> *will* require changes in clients that look at pg_attribute.
>
> > Uh, Christopher already indicated three clients, psql, pg_dump, and
> > a
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I used the following macro in my trial implementation.
> > #define COLUMN_IS_DROPPED(attribute) ((attribute)->attnum <=
> > DROP_COLUMN_OFFSET)
> > The places where the macro was put are exactly the places
> > where attisdropped mu
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> No, he only breaks even for client cleanliness --- either approach
>> *will* require changes in clients that look at pg_attribute.
> Uh, Christopher already indicated three clients, psql, pg_dump, and
> another that will not require c
pgman wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > The following patch fixes all of these, and it will be in 7.3.
> >
> > It will? Kindly explain what the heck this is doing. It looks to
> > me like it will probably break more cases than it fixes. AFAICS
> > it'
> Well in the renumbering case, the client needs to know about missing attnos
> and it has to know to ignore negative attnos (which it probably does
> already). ie. psql and pg_dump wouldn't have to be modified in that case.
> In the isdropped case, the client needs to know to exclude any column
31 matches
Mail list logo
