7.2 stuff

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

How far off is 7.2? Ages?

Hopefully not. I'd like to see us get back on a reasonably short
release cycle, like every six months or less --- the last couple
major release cycles have been painfully long.

So, maybe beta around Aug-Sep?

Not speaking on behalf of core here; we haven't discussed release
schedule at all yet. Just my personal $0.02.

* Check that pgclass.relfkeys is being set correctly.
- Is pgclass.relfkeys being used at the moment?

A quick glimpse shows not. I have a personal todo item to fix
relhaspkey, which isn't implemented either. Feel free to fix this
one if it bugs you. (Note: it might be harder than it looks; think
about race conditions when different backends are adding/dropping
keys concurrently.)

* MOVE ALTER CODE FROM heap.c/command.c INTO alter.c
- I get the feeling I'm filling up heap.c with lots of alter table crud
that is beginning to need its own file?

Code beautification efforts are always worthwhile IMHO.

regards, tom lane

On Thu, 21 Jun 2001, Tom Lane wrote:

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

How far off is 7.2? Ages?

Hopefully not. I'd like to see us get back on a reasonably short
release cycle, like every six months or less --- the last couple
major release cycles have been painfully long.

So, maybe beta around Aug-Sep?

Not speaking on behalf of core here; we haven't discussed release
schedule at all yet. Just my personal $0.02.

That's what I was seeing/hoping for also ...

So you have at ~2 months.

How far off is 7.2? Ages? I want to add the rest of the ALTER TABLE
functionality for 7.2, but I've just been busy - don't worry I haven't
forgotten!

This is my personal TODO list:

* ALTER TABLE ADD PRIMARY KEY
- Done, except code that detects whether or not a pk already exists
* ALTER TABLE ADD UNIQUE
- Done, except code that detects whether or not a unique key already exists
over the specified fields
* PSQL - SHOW FOREIGN KEYS
- Still working on a query. If I come up with a good one - would a catalog
view of them be useful?
* -ALTER TABLE DROP CHECK
- Already committed
* ALTER TABLE DROP PRIMARY KEY
- Done, will need review
* ALTER TABLE DROP UNIQUE
- Done, will need review
* ALTER TABLE DROP FOREIGN KEY
- Harder than I thought :) Working on it.
* Check that pgclass.relfkeys is being set correctly.
- Is pgclass.relfkeys being used at the moment?
* PG_DUMP DUMP CONSTRAINTS AS ALTER TABLE STATEMENTS
- Would be nice, once the alter statements above work.
* FIX 'RESTRICT' IN DROP CONSTRAINT DOCS
- It would be nice to have restrict/cascade as optional keywords at the
moment? At the moment, the grammar forces people to put the word 'restrict'
in, even though it does nothing.
* REGRESSION TESTS
- For all of the above
* WILDCARDS IN PG_DUMP
- It would be nice to be able to dump tables via wildcards, or once schemas
exist to dump an entire schema I guess.
* CHECK CREATING DUPLICATE NAMED FOREIGN KEYS
- I seem to be able to create duplicate named fk's, plus I think the
'<unnamed>' ones should be given auto name to make dropping constraint
easier...
* DOCUMENT PG_TRIGGER
- Doesn't seem to be in the system catalog documentation...
* MOVE ALTER CODE FROM heap.c/command.c INTO alter.c
- I get the feeling I'm filling up heap.c with lots of alter table crud
that is beginning to need its own file?

If anyone is super-interested in seeing my unposted code, feel free to ask
for it. (Or better yet, wants to finish the work ;) )

Chris

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

This is a nice list and all are good items. People should be able to
help you if you encounter problems.

How far off is 7.2? Ages? I want to add the rest of the ALTER TABLE
functionality for 7.2, but I've just been busy - don't worry I haven't
forgotten!

This is my personal TODO list:

* ALTER TABLE ADD PRIMARY KEY
- Done, except code that detects whether or not a pk already exists
* ALTER TABLE ADD UNIQUE
- Done, except code that detects whether or not a unique key already exists
over the specified fields
* PSQL - SHOW FOREIGN KEYS
- Still working on a query. If I come up with a good one - would a catalog
view of them be useful?
* -ALTER TABLE DROP CHECK
- Already committed
* ALTER TABLE DROP PRIMARY KEY
- Done, will need review
* ALTER TABLE DROP UNIQUE
- Done, will need review
* ALTER TABLE DROP FOREIGN KEY
- Harder than I thought :) Working on it.
* Check that pgclass.relfkeys is being set correctly.
- Is pgclass.relfkeys being used at the moment?
* PG_DUMP DUMP CONSTRAINTS AS ALTER TABLE STATEMENTS
- Would be nice, once the alter statements above work.
* FIX 'RESTRICT' IN DROP CONSTRAINT DOCS
- It would be nice to have restrict/cascade as optional keywords at the
moment? At the moment, the grammar forces people to put the word 'restrict'
in, even though it does nothing.
* REGRESSION TESTS
- For all of the above
* WILDCARDS IN PG_DUMP
- It would be nice to be able to dump tables via wildcards, or once schemas
exist to dump an entire schema I guess.
* CHECK CREATING DUPLICATE NAMED FOREIGN KEYS
- I seem to be able to create duplicate named fk's, plus I think the
'<unnamed>' ones should be given auto name to make dropping constraint
easier...
* DOCUMENT PG_TRIGGER
- Doesn't seem to be in the system catalog documentation...
* MOVE ALTER CODE FROM heap.c/command.c INTO alter.c
- I get the feeling I'm filling up heap.c with lots of alter table crud
that is beginning to need its own file?

If anyone is super-interested in seeing my unposted code, feel free to ask
for it. (Or better yet, wants to finish the work ;) )

Chris

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Christopher, do you want any of this added to the TODO?

---------------------------------------------------------------------------

How far off is 7.2? Ages? I want to add the rest of the ALTER TABLE
functionality for 7.2, but I've just been busy - don't worry I haven't
forgotten!

This is my personal TODO list:

* ALTER TABLE ADD PRIMARY KEY
- Done, except code that detects whether or not a pk already exists
* ALTER TABLE ADD UNIQUE
- Done, except code that detects whether or not a unique key already exists
over the specified fields
* PSQL - SHOW FOREIGN KEYS
- Still working on a query. If I come up with a good one - would a catalog
view of them be useful?
* -ALTER TABLE DROP CHECK
- Already committed
* ALTER TABLE DROP PRIMARY KEY
- Done, will need review
* ALTER TABLE DROP UNIQUE
- Done, will need review
* ALTER TABLE DROP FOREIGN KEY
- Harder than I thought :) Working on it.
* Check that pgclass.relfkeys is being set correctly.
- Is pgclass.relfkeys being used at the moment?
* PG_DUMP DUMP CONSTRAINTS AS ALTER TABLE STATEMENTS
- Would be nice, once the alter statements above work.
* FIX 'RESTRICT' IN DROP CONSTRAINT DOCS
- It would be nice to have restrict/cascade as optional keywords at the
moment? At the moment, the grammar forces people to put the word 'restrict'
in, even though it does nothing.
* REGRESSION TESTS
- For all of the above
* WILDCARDS IN PG_DUMP
- It would be nice to be able to dump tables via wildcards, or once schemas
exist to dump an entire schema I guess.
* CHECK CREATING DUPLICATE NAMED FOREIGN KEYS
- I seem to be able to create duplicate named fk's, plus I think the
'<unnamed>' ones should be given auto name to make dropping constraint
easier...
* DOCUMENT PG_TRIGGER
- Doesn't seem to be in the system catalog documentation...
* MOVE ALTER CODE FROM heap.c/command.c INTO alter.c
- I get the feeling I'm filling up heap.c with lots of alter table crud
that is beginning to need its own file?

If anyone is super-interested in seeing my unposted code, feel free to ask
for it. (Or better yet, wants to finish the work ;) )

Chris

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Well, it was just a bunch of stuff I wanted to work on, feel free to add it
to the TODO list. Some comments are below.

* ALTER TABLE ADD PRIMARY KEY
- Done, except code that detects whether or not a pk already exists
* ALTER TABLE ADD UNIQUE
- Done, except code that detects whether or not a unique

The ADD UNIQUE stuff is in 7.2, however Tom Lane has suggested that there
are some stylistic deficiencies in the code that should be improved. I
won't be able to correct these before 7.2 release, as it involves me sitting
down for hours searching the souce code for function definitions, figuring
out how the work, etc. In fact, I'm sure a more experienced developer could
perform the fixes in 10 mins...

This problem is also what's stopped me submitting the ALTER TABLE / ADD
PRIMARY stuff. Once the ADD UNIQUE bit is correct, ADD PRIMARY is trivial.

(See: http://fts.postgresql.org/db/mw/msg.html?mid=1035632) I suggest
reading the complete thread. I have fixed some of the problems in my
private cvs, but no patch has been sent in...

Some of the issues perhaps I should send in a patch for ASAP??

key already exists

over the specified fields
* PSQL - SHOW FOREIGN KEYS
- Still working on a query. If I come up with a good one -

would a catalog

view of them be useful?

Is there a pg_get_* function for getting foreign key definitions yet?

* -ALTER TABLE DROP CHECK
- Already committed

Yeah, committed.

* ALTER TABLE DROP PRIMARY KEY
- Done, will need review
* ALTER TABLE DROP UNIQUE
- Done, will need review

Wrote them, but they're uncommitted. Don't worry about them until 7.3.

* ALTER TABLE DROP FOREIGN KEY
- Harder than I thought :) Working on it.

This is a toughie this one!

* Check that pgclass.relfkeys is being set correctly.
- Is pgclass.relfkeys being used at the moment?

It looked to me that pgclass.relfkeys wasn't ever being set or updated. Is
this true/correct?

* PG_DUMP DUMP CONSTRAINTS AS ALTER TABLE STATEMENTS
- Would be nice, once the alter statements above work.
* FIX 'RESTRICT' IN DROP CONSTRAINT DOCS
- It would be nice to have restrict/cascade as optional

keywords at the

moment? At the moment, the grammar forces people to put the

word 'restrict'

in, even though it does nothing.

Don't bother about this - it's been documented.

* REGRESSION TESTS
- For all of the above

I've comment a regression test for ADD UNIQUE, but I don't think the DROP
CONSTRAINT stuff has a regression test yet.

* WILDCARDS IN PG_DUMP
- It would be nice to be able to dump tables via wildcards,

or once schemas

exist to dump an entire schema I guess.

That was just one of my little wish lists. I have a database with about a
hundred tables in it and related sets of tables all share the same prefix.
For instance, I would like to be able to pg_dump all the diary tables in one
go.

ie. pg_dump -t diary_\* audb > dump.sql

Don't know if there would be widespread enough demand for this feature
tho...

* CHECK CREATING DUPLICATE NAMED FOREIGN KEYS
- I seem to be able to create duplicate named fk's, plus I think the
'<unnamed>' ones should be given auto name to make dropping constraint
easier...

Pretty clear.

* DOCUMENT PG_TRIGGER
- Doesn't seem to be in the system catalog documentation...

Yeah, pg_trigger does not appear on this page:

http://postgresql.planetmirror.com/devel-corner/docs/postgres/catalogs.html

Thought it should be documented. I noticed this while I was doing the
improvements on the contrib/fulltextindex code.

* MOVE ALTER CODE FROM heap.c/command.c INTO alter.c
- I get the feeling I'm filling up heap.c with lots of

alter table crud

that is beginning to need its own file?

Basically I was getting the impression that the command.c was getting big
and fat and that it might be nice to split all the ALTER* commands into an
alter.c or something.

Tell me what I should do for 7.2...

Regards,

Chris

Basically I was getting the impression that the command.c was getting big
and fat and that it might be nice to split all the ALTER* commands into an
alter.c or something.

Tell me what I should do for 7.2...

I think 7.2 is fine. We can start on 7.3 in a few weeks.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

Tell me what I should do for 7.2...

At this point, none of these are on the radar screen for 7.2; we are in
"get the release out" mode, and anything that's not a critical bug fix
need not apply. But here are some comments for 7.3 and beyond.

Is there a pg_get_* function for getting foreign key definitions yet?

No, but it seems like possibly a good idea. We should try to move away
from applications looking directly at the system catalogs, and introduce
some layer of indirection so that catalog changes don't break so many
things. pg_get_xxx functions are one approach. Peter E. has suggested
that implementing the SQL92 informational views might be a better (more
standards-compliant) way of providing that indirection. That's cool to
the extent that it works, but I wonder whether we won't find that the
SQL92 views omit important Postgres extensions. Anyway, this is a
long-term project.

It looked to me that pgclass.relfkeys wasn't ever being set or updated. Is
this true/correct?

I cannot find any references to it in the code, either.

For instance, I would like to be able to pg_dump all the diary tables in one
go.
ie. pg_dump -t diary_\* audb > dump.sql
Don't know if there would be widespread enough demand for this feature
tho...

I've seen requests for that before ... and I don't think they were all
from you ;-). Seems like a reasonable wishlist item to me.

* DOCUMENT PG_TRIGGER
- Doesn't seem to be in the system catalog documentation...
Yeah, pg_trigger does not appear on this page:

It's in the current sources. Perhaps you're looking at an obsolete
mirror?

Basically I was getting the impression that the command.c was getting big
and fat and that it might be nice to split all the ALTER* commands into an
alter.c or something.

Cool with me. We often fail to spend enough effort on code
beautification projects; that hurts the maintainability of the project
in the long run. Feel free to devise and implement a better division
of the ALTER code. (And as I think we already talked about, it'd also
be cool to try to merge the common infrastructure of the ALTER commands
somehow. I don't like umpteen copied-and-pasted versions of the same
code, either ...)

regards, tom lane

At 23:21 26/11/01 -0500, Tom Lane wrote:

For instance, I would like to be able to pg_dump all the diary tables in

one

go.
ie. pg_dump -t diary_\* audb > dump.sql
Don't know if there would be widespread enough demand for this feature
tho...

I've seen requests for that before ... and I don't think they were all
from you ;-). Seems like a reasonable wishlist item to me.

I have been sent patches for this kind of thing, but I would like to see
them generalized to some extent. Not sure of the syntax, but I'd like to be
able to dump *any* selected pg_dump TOC entry type by name, or partial name
match. ie. tables, functions, indexes, etc.

Any suggestions as to how this is best done within unix-like commands? eg.

pg_dump/restore --select=table:<regexp> ?
pg_dump/restore --select=index:<regexp> ?

Any ideas?

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

In article <17242.1006834868@sss.pgh.pa.us>, "Tom Lane"
<tgl@sss.pgh.pa.us> wrote:

Basically I was getting the impression that the command.c was getting
big and fat and that it might be nice to split all the ALTER* commands
into an alter.c or something.

Cool with me. We often fail to spend enough effort on code
beautification projects; that hurts the maintainability of the project
in the long run. Feel free to devise and implement a better division of
the ALTER code. (And as I think we already talked about, it'd also be
cool to try to merge the common infrastructure of the ALTER commands
somehow. I don't like umpteen copied-and-pasted versions of the same
code, either ...)

I'd started a little of this with my TOAST slicing patch -moving some
common code around in command.c (standard permissions checking and
recursing over children) to eliminate duplicates.

I'm still sitting on the patch and maintaining separately because it is
for 7.3, but I am quite interested in some further tidying, but I don't
want to load too much into a single patch.

Regards

John

--
John Gray
Azuli IT http://www.azuli.co.uk +44 121 693 3397
jgray@azuli.co.uk

Are there any TODO items here?

---------------------------------------------------------------------------

Christopher Kings-Lynne wrote:

Well, it was just a bunch of stuff I wanted to work on, feel free to add it
to the TODO list. Some comments are below.

* ALTER TABLE ADD PRIMARY KEY
- Done, except code that detects whether or not a pk already exists
* ALTER TABLE ADD UNIQUE
- Done, except code that detects whether or not a unique

The ADD UNIQUE stuff is in 7.2, however Tom Lane has suggested that there
are some stylistic deficiencies in the code that should be improved. I
won't be able to correct these before 7.2 release, as it involves me sitting
down for hours searching the souce code for function definitions, figuring
out how the work, etc. In fact, I'm sure a more experienced developer could
perform the fixes in 10 mins...

This problem is also what's stopped me submitting the ALTER TABLE / ADD
PRIMARY stuff. Once the ADD UNIQUE bit is correct, ADD PRIMARY is trivial.

(See: http://fts.postgresql.org/db/mw/msg.html?mid=1035632) I suggest
reading the complete thread. I have fixed some of the problems in my
private cvs, but no patch has been sent in...

Some of the issues perhaps I should send in a patch for ASAP??

key already exists

over the specified fields
* PSQL - SHOW FOREIGN KEYS
- Still working on a query. If I come up with a good one -

would a catalog

view of them be useful?

Is there a pg_get_* function for getting foreign key definitions yet?

* -ALTER TABLE DROP CHECK
- Already committed

Yeah, committed.

* ALTER TABLE DROP PRIMARY KEY
- Done, will need review
* ALTER TABLE DROP UNIQUE
- Done, will need review

Wrote them, but they're uncommitted. Don't worry about them until 7.3.

* ALTER TABLE DROP FOREIGN KEY
- Harder than I thought :) Working on it.

This is a toughie this one!

* Check that pgclass.relfkeys is being set correctly.
- Is pgclass.relfkeys being used at the moment?

It looked to me that pgclass.relfkeys wasn't ever being set or updated. Is
this true/correct?

* PG_DUMP DUMP CONSTRAINTS AS ALTER TABLE STATEMENTS
- Would be nice, once the alter statements above work.
* FIX 'RESTRICT' IN DROP CONSTRAINT DOCS
- It would be nice to have restrict/cascade as optional

keywords at the

moment? At the moment, the grammar forces people to put the

word 'restrict'

in, even though it does nothing.

Don't bother about this - it's been documented.

* REGRESSION TESTS
- For all of the above

I've comment a regression test for ADD UNIQUE, but I don't think the DROP
CONSTRAINT stuff has a regression test yet.

* WILDCARDS IN PG_DUMP
- It would be nice to be able to dump tables via wildcards,

or once schemas

exist to dump an entire schema I guess.

That was just one of my little wish lists. I have a database with about a
hundred tables in it and related sets of tables all share the same prefix.
For instance, I would like to be able to pg_dump all the diary tables in one
go.

ie. pg_dump -t diary_\* audb > dump.sql

Don't know if there would be widespread enough demand for this feature
tho...

* CHECK CREATING DUPLICATE NAMED FOREIGN KEYS
- I seem to be able to create duplicate named fk's, plus I think the
'<unnamed>' ones should be given auto name to make dropping constraint
easier...

Pretty clear.

* DOCUMENT PG_TRIGGER
- Doesn't seem to be in the system catalog documentation...

Yeah, pg_trigger does not appear on this page:

http://postgresql.planetmirror.com/devel-corner/docs/postgres/catalogs.html

Thought it should be documented. I noticed this while I was doing the
improvements on the contrib/fulltextindex code.

* MOVE ALTER CODE FROM heap.c/command.c INTO alter.c
- I get the feeling I'm filling up heap.c with lots of

alter table crud

that is beginning to need its own file?

Basically I was getting the impression that the command.c was getting big
and fat and that it might be nice to split all the ALTER* commands into an
alter.c or something.

Tell me what I should do for 7.2...

Regards,

Chris

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Reminder that code cleanup can be done in commands/*.

---------------------------------------------------------------------------

Tom Lane wrote:

Basically I was getting the impression that the command.c was getting big
and fat and that it might be nice to split all the ALTER* commands into an
alter.c or something.

Cool with me. We often fail to spend enough effort on code
beautification projects; that hurts the maintainability of the project
in the long run. Feel free to devise and implement a better division
of the ALTER code. (And as I think we already talked about, it'd also
be cool to try to merge the common infrastructure of the ALTER commands
somehow. I don't like umpteen copied-and-pasted versions of the same
code, either ...)

regards, tom lane

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Hi,

Tom - there's a comment for you further down...

This problem is also what's stopped me submitting the ALTER TABLE / ADD
PRIMARY stuff. Once the ADD UNIQUE bit is correct, ADD PRIMARY

is trivial.

(See: http://fts.postgresql.org/db/mw/msg.html?mid=1035632) I suggest
reading the complete thread. I have fixed some of the problems in my
private cvs, but no patch has been sent in...

Some of the issues perhaps I should send in a patch for ASAP??

All of the above is a non-issue - it was implemented by tom in the parser,
and my code was removed. Howver, add primary key needs a regression test.

key already exists

over the specified fields
* PSQL - SHOW FOREIGN KEYS
- Still working on a query. If I come up with a good one -

would a catalog

view of them be useful?

Is there a pg_get_* function for getting foreign key definitions yet?

I still want to do the above - however Stephen Sazbo has ideas about
changing all the fk stuff...

* -ALTER TABLE DROP CHECK
- Already committed

Yeah, committed.

Committed - it needs a regression test tho.

* ALTER TABLE DROP PRIMARY KEY
- Done, will need review
* ALTER TABLE DROP UNIQUE
- Done, will need review

Wrote them, but they're uncommitted. Don't worry about them until 7.3.

I'll dredge this up again if I can. All it does is add a standards
compliant alternative syntax for dropping those constraints. Tom - can you
just do this in the parser, like you did it for the ADD constraints???

* ALTER TABLE DROP FOREIGN KEY
- Harder than I thought :) Working on it.

This is a toughie this one!

And also depends on future fk changes.

* Check that pgclass.relfkeys is being set correctly.
- Is pgclass.relfkeys being used at the moment?

It looked to me that pgclass.relfkeys wasn't ever being set or

updated. Is

this true/correct?

Correct.

* WILDCARDS IN PG_DUMP
- It would be nice to be able to dump tables via wildcards,

or once schemas

exist to dump an entire schema I guess.

That was just one of my little wish lists. I have a database

with about a

hundred tables in it and related sets of tables all share the

same prefix.

For instance, I would like to be able to pg_dump all the diary

tables in one

go.

ie. pg_dump -t diary_\* audb > dump.sql

Don't know if there would be widespread enough demand for this feature
tho...

The above would be a nice feature...

* CHECK CREATING DUPLICATE NAMED FOREIGN KEYS
- I seem to be able to create duplicate named fk's,

plus I think the

'<unnamed>' ones should be given auto name to make dropping

constraint

easier...

Pretty clear.

Chris

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

* ALTER TABLE DROP PRIMARY KEY
- Done, will need review
* ALTER TABLE DROP UNIQUE
- Done, will need review

I'll dredge this up again if I can. All it does is add a standards
compliant alternative syntax for dropping those constraints. Tom - can you
just do this in the parser, like you did it for the ADD constraints???

I don't foresee it falling out of other parser work, if that's what you
mean. If you want it done in the parser you'll have to do it yourself.

There are some semantic issues, eg: what does it mean to do ALTER TABLE
DROP PRIMARY KEY in an inheritance hierarchy? Does every child lose its
primary key (if any), even if it's not inherited from the parent?
I could see doing the "where's the primary key" lookup either at
execution time (separately for each table) or at parse time (lookup once
at the parent table) depending on which behavior you want.

regards, tom lane

On Mon, 2002-02-25 at 07:53, Tom Lane wrote:

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

* ALTER TABLE DROP PRIMARY KEY
- Done, will need review
* ALTER TABLE DROP UNIQUE
- Done, will need review

I'll dredge this up again if I can. All it does is add a standards
compliant alternative syntax for dropping those constraints. Tom - can you
just do this in the parser, like you did it for the ADD constraints???

I don't foresee it falling out of other parser work, if that's what you
mean. If you want it done in the parser you'll have to do it yourself.

There are some semantic issues, eg: what does it mean to do ALTER TABLE
DROP PRIMARY KEY in an inheritance hierarchy? Does every child lose its
primary key (if any), even if it's not inherited from the parent?

Probably not as the primary key is currently not inherited when doing
create.

------------
Hannu

On Mon, 2002-02-25 at 07:44, Christopher Kings-Lynne wrote:

key already exists

over the specified fields
* PSQL - SHOW FOREIGN KEYS
- Still working on a query. If I come up with a good one -

would a catalog

view of them be useful?

Is there a pg_get_* function for getting foreign key definitions yet?

I still want to do the above - however Stephen Sazbo has ideas about
changing all the fk stuff...

That makes it almost mandatory - how else will we be able to dump/reload
fk's for the new fk implementation?

---------
Hannu

On Sun, 24 Feb 2002, Tom Lane wrote:

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

* ALTER TABLE DROP PRIMARY KEY
- Done, will need review
* ALTER TABLE DROP UNIQUE
- Done, will need review

I'll dredge this up again if I can. All it does is add a standards
compliant alternative syntax for dropping those constraints. Tom - can you
just do this in the parser, like you did it for the ADD constraints???

I don't foresee it falling out of other parser work, if that's what you
mean. If you want it done in the parser you'll have to do it yourself.

There are some semantic issues, eg: what does it mean to do ALTER TABLE
DROP PRIMARY KEY in an inheritance hierarchy? Does every child lose its
primary key (if any), even if it's not inherited from the parent?

Apart from the fact that currently pkeys don't inherit, does it make
sense that the child can have a separate primary key since it should
really be inheriting from the parent and you can't have two, right?