> -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
"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'
"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
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 w
> > 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 inherite
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.
---
Chri
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
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
> 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 w
> 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
> 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
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
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 pg_attr
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 mus
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
> semanticall
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, you
> 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
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
> > 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
> > 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
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
> > > > 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:
> > > 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 t
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 te
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
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 t
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 rem
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
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 hopefu
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.
>
>
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 rol
> > 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
> 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 t
> all values, drop the old col). So, there is no reason why this new
> attisdropped field shouldn't allow us to implement a full ALTER TABLE/SET
> TYPE sort of feature - cool huh?
I've not looked in a while, but the column rename code did not account
for issues in foreign keys, etc. Those shou
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 instead, I've taken up with the DROP COLUM
53 matches
Mail list logo
