-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
"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
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
What happens if I drop an inherited column in a child table? Maybe it
works, but what happens when I SELECT the column in the parent table?
Well, what happens if you rename a column in a child table? Same problem?
Ideally we should disallow
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
1. I'm going to prevent people from dropping the last column in their table.
I think this is the safest option. How do I check if there's any other non
dropped columns in a table? Reference code anywhere?
You look through the Relation's
The problem is that the new column is now part of pg_attribute so every
catalog/pg_attribute.h DATA() line has to be updated. Did you update
them all with 'false' in the right slot? Not sure what the chunks are.
---
Well, what happens if you rename a column in a child table?
Same problem?
It merrily renames the column in the child table (I tried it). When
SELECTing the parent, bogus data appears. Looks like a bug to me.
Maybe the ALTER TABLE ... RENAME COLUMN code should check for inherited
Rod Taylor wrote:
We could change pg_attribute to another name, and create a view called
pg_attribute that never returned isdropped columns to the client. That
would allow clients to work cleanly, and the server to work cleanly.
Another case where having an informational schema would
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.
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
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
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
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.
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
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
I've not looked in a while, but the column rename code did not account
for issues in foreign keys, etc. Those should be easier to ferret out
soon, but may not be so nice to change yet.
Which is probably a good reason for us to offer it as an all-in-one command,
rather than expecting them to
It should also be noted that an ALTER TABLE / SET TYPE implemented with
the above idea with run into the 2x diskspace issue as well as take
quite a while to process.
I think that if the 'SET TYPE' operation is ever to be rollback-able, it
will need to use 2x diskspace. If it's
On Wed, 2002-07-03 at 14:32, Rod Taylor wrote:
It should also be noted that an ALTER TABLE / SET TYPE implemented with
the above idea with run into the 2x diskspace issue as well as take
quite a while to process.
I think that if the 'SET TYPE' operation is ever to be rollback-able,
Christopher Kings-Lynne wrote:
Hi All,
I have given up working on the BETWEEN node. It got to the stage where I
realised I was really out of my depth! Rod Taylor has indicated an interest
in the problem and I have sent him my latest patch, so hopefully he'll be
able to crack it.
So
Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
Hi All,
I have given up working on the BETWEEN node. It got to the stage where I
realised I was really out of my depth! Rod Taylor has indicated an interest
in the problem and I have sent him my latest patch, so hopefully he'll
Hiroshi Inoue wrote:
As I remember, Hiroshi's drop column changed the attribute number to a
special negative value, which required lots of changes to track.
??? What do you mean by *lots of* ?
Yes, please remind me. Was your solution renumbering the attno values?
I think there are fewer
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
As I remember, Hiroshi's drop column changed the attribute number to a
special negative value, which required lots of changes to track.
??? What do you mean by *lots of* ?
Yes, please remind me. Was your
Bruce Momjian wrote:
Hiroshi Inoue wrote:
As I remember, Hiroshi's drop column changed the attribute number to a
special negative value, which required lots of changes to track.
??? What do you mean by *lots of* ?
Yes, please remind me. Was your solution renumbering the attno
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
As I remember, Hiroshi's drop column changed the attribute number to a
special negative value, which required lots of changes to track.
??? What do you mean by *lots of* ?
Yes,
Christopher Kings-Lynne wrote:
Yes, please remind me. Was your solution renumbering the
attno values?
Yes though I don't intend to object to Christopher's proposal.
Hiroshi,
I am thinking of rolling back my CVS to see if there's code from your
previous test implementation
Christopher Kings-Lynne wrote:
I am thinking of rolling back my CVS to see if there's code from your
previous test implementation that we can use. Apart from the DropColumn
function itself, what other changes did you make? Did you have
modifications for '*' expansion in the parser,
Yes, please remind me. Was your solution renumbering the
attno values?
Yes though I don't intend to object to Christopher's proposal.
Hiroshi,
I am thinking of rolling back my CVS to see if there's code from your
previous test implementation that we can use. Apart from the
Christopher Kings-Lynne wrote:
Yes, please remind me. Was your solution renumbering the
attno values?
Yes though I don't intend to object to Christopher's proposal.
Hiroshi,
I am thinking of rolling back my CVS to see if there's code from your
previous test implementation
I am thinking of rolling back my CVS to see if there's code from your
previous test implementation that we can use. Apart from the DropColumn
function itself, what other changes did you make? Did you have
modifications for '*' expansion in the parser, etc.?
Yes, please review
Well, obviously I prefer the attisdropped approach. I think
it's clearer
and there's less confusion. As a head developer for phpPgAdmin
that's what
I'd prefer... Hiroshi obviously prefers his solution, but
doesn't object to
OK, can you explain the issues from a server and client
Christopher Kings-Lynne wrote:
Well, obviously I prefer the attisdropped approach. I think
it's clearer
and there's less confusion. As a head developer for phpPgAdmin
that's what
I'd prefer... Hiroshi obviously prefers his solution, but
doesn't object to
OK, can you explain
Unfortunately many apps rely on the fact that the attnos are
consecutive starting from 1. It was the main reason why Tom
rejected my trial. Nothing has changed about it.
OK, I've been looking at Hiroshi's implementation. It's basically
semantically equivalent to mine from what I can see so
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.
Actually, your trial
Christopher Kings-Lynne wrote:
Unfortunately many apps rely on the fact that the attnos are
consecutive starting from 1. It was the main reason why Tom
rejected my trial. Nothing has changed about it.
OK, I've been looking at Hiroshi's implementation. It's basically
semantically
49 matches
Mail list logo
