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 must be checked.
Gavin, I will need a doc patch for this too. Thanks.
---
Gavin Sherry wrote:
Slight bug in the previous patch. Logically (and according to SQL99's
treatment of ON COMMIT), it can be specified only for CREATE TEMP
Bruce Momjian [EMAIL PROTECTED] writes:
It may turn out to be a choice of client-cleanliness vs. backend
cleanliness. Seems Hiroshi already wins for client cleanliness.
No, he only breaks even for client cleanliness --- either approach
*will* require changes in clients that look at
Seems we may not need isdropped, so I will hold on evaluating this.
---
Christopher Kings-Lynne wrote:
Hi,
I've attached the changes I've made to pg_attribute.h - I can't see what's
wrong but whenever I do an initdb
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
It may turn out to be a choice of client-cleanliness vs. backend
cleanliness. Seems Hiroshi already wins for client cleanliness.
No, he only breaks even for client cleanliness --- either approach
*will* require changes in clients
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
... The following patch fixes the libpqxx
compile problem on FreeBSD/alpha. The old code set -O2 for
FreeBSD/i386, but that is already set earlier. The new patch just
updates the FreeBSD/alpha compile.
As a general rule,
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
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's just
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 changes
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 stumbled over it
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 relcache.c
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 be
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
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
we
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
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 be
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
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
found
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
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, but that'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 changes for
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 stumbled over it
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
-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
don't look
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, but
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 column.
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 I am
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 to
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
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
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 -
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.
Apparently
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 it?
33 matches
Mail list logo
