On Thu, 2006-06-08 at 17:23 -0400, Greg Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2006-06-08 at 16:47 -0400, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
So? They'll get re-merged with the parent column during CREATE
But that's entirely inconsistent with the way inherited tables
work
in general.
I don't see any basis for that conclusion. The properties of a
table
are set when it's created and you need to do pretty explicit ALTERs
to
change them.
It just seems weird for:
CREATE TABLE
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes:
Imho the op should only choose that path if he wants to fill the table
before adding the inheritance. It makes no sense to add columns with default
values to existing rows of the child table, especially when you inherit the
defaults from
I can't find any standard api to remove a single specific dependency. It seems
normally dependencies are only removed when dropping objects via
performDeletion.
Should I just put a scan of pg_depend in ATExecDropInherits or should I add a
new function to pg_depend or somewhere else to handle
Ühel kenal päeval, N, 2006-06-08 kell 09:32, kirjutas Greg Stark:
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes:
Imho the op should only choose that path if he wants to fill the table
before adding the inheritance. It makes no sense to add columns with default
values to existing
Greg Stark wrote:
I can't find any standard api to remove a single specific dependency. It seems
normally dependencies are only removed when dropping objects via
performDeletion.
Huh, and can't you just drop an inheritance entry with performDeletion?
Maybe what you should do is add support
Alvaro Herrera [EMAIL PROTECTED] writes:
Greg Stark wrote:
I can't find any standard api to remove a single specific dependency. It
seems
normally dependencies are only removed when dropping objects via
performDeletion.
Huh, and can't you just drop an inheritance entry with
Hannu Krosing [EMAIL PROTECTED] writes:
Do you mean that in newer versions ALTER TABLE ADD COLUMN will change
existing data without asking me ?
That would be evil!
Even worse if ALTER TABLE ALTER COLUMN SET DEFAULT would do the same.
postgres=# alter table test add b integer default 1;
Greg Stark [EMAIL PROTECTED] writes:
Come to think of it it's pretty strange that you can drop an inherited
constraint from a child. And doing an experiment it seems you can also DROP
NOT NULL on a child which is also pretty strange.
Yeah. I think we had agreed that this is a bug. Note the
On Thu, Jun 08, 2006 at 11:42:49AM -0400, Greg Stark wrote:
It was awfully annoying for users when that feature was missing.
Any non-linearities in the user interface like this
end up being surprises and annoyances for users.
I would be *really*, *really*, *really* annoyed if an op
Jim C. Nasby [EMAIL PROTECTED] writes:
On Thu, Jun 08, 2006 at 11:42:49AM -0400, Greg Stark wrote:
But I seem to recall some headaches with that approach.
What happens if you
ALTER TABLE ... ADD new_column int DEFAULT 1;
ALTER TABLE ... ALTER new_column SET DEFAULT 2;
Ah yes. Keeping
On Thu, Jun 08, 2006 at 12:19:49PM -0400, Greg Stark wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Thu, Jun 08, 2006 at 11:42:49AM -0400, Greg Stark wrote:
But I seem to recall some headaches with that approach.
What happens if you
ALTER TABLE ... ADD new_column int DEFAULT
Greg Stark wrote:
Well I'm not actually deleting anything. The dependency is between the two
tables and I don't want to delete either of the tables.
Perhaps what should really be happening here is that there should be
dependencies from the pg_inherit entry to the two tables rather than from
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Come to think of it it's pretty strange that you can drop an inherited
constraint from a child. And doing an experiment it seems you can also DROP
NOT NULL on a child which is also pretty strange.
Yeah. I think we
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
The implementation I had in mind was to add columns similar to attinhcount
and attislocal to pg_constraint.
Hm that would be simpler. That still leaves NOT NULL as a bit of a headache.
Yeah, I think we would want to
Greg Stark [EMAIL PROTECTED] writes:
Perhaps what should really be happening here is that there should be
dependencies from the pg_inherit entry to the two tables rather than from one
table to the other.
This seems unlikely to still have the correct semantics (DROP on child
is OK, DROP on
Alvaro Herrera [EMAIL PROTECTED] writes:
Greg Stark wrote:
Well I'm not actually deleting anything. The dependency is between the two
tables and I don't want to delete either of the tables.
Perhaps what should really be happening here is that there should be
dependencies from the
Greg Stark [EMAIL PROTECTED] writes:
I'm a bit confused about what pg_depends entries would be necessary then. If
there's something like this there:
Child Table --(AUTO)-- pg_inherit entry --(NORMAL)- Parent Table
I think that would work, but it seems pretty baroque. pg_inherit
entries are
Tom Lane [EMAIL PROTECTED] writes:
BTW ... are you intending to renumber inhseqno entries of remaining
pg_inherits items after DROP INHERITS? Which seqno will be assigned
by ADD INHERITS? This seems like another area in which DROP/ADD will
not be a complete no-op.
I assigned inhseqno to be
Greg Stark [EMAIL PROTECTED] writes:
It's not a precise noop in database internal data structures, but I don't see
any user-visible effects switching around seqnos would have. But maybe there's
something I don't know about?
It'll affect the order in which pg_dump lists the parents, which will
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
It's not a precise noop in database internal data structures, but I don't
see
any user-visible effects switching around seqnos would have. But maybe
there's
something I don't know about?
It'll affect the
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
It'll affect the order in which pg_dump lists the parents, which will
affect the order in which the columns are created on dump and reload.
Hm, if column order is important for table with multiple parents then you have
Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
It's not a precise noop in database internal data structures, but I don't see
any user-visible effects switching around seqnos would have. But maybe there's
something I don't know about?
Ühel kenal päeval, N, 2006-06-08 kell 11:42, kirjutas Greg Stark:
Hannu Krosing [EMAIL PROTECTED] writes:
Do you mean that in newer versions ALTER TABLE ADD COLUMN will change
existing data without asking me ?
That would be evil!
Even worse if ALTER TABLE ALTER COLUMN SET DEFAULT
Hannu Krosing [EMAIL PROTECTED] writes:
I remember that discussion, but I'm surprised that something got
implemented and accepted into core with so many unsolvable
problems/logical inconsistencies/new pitfalls.
The current behavior of ALTER ADD COLUMN SET DEFAULT is per SQL spec.
If you feel
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
It'll affect the order in which pg_dump lists the parents, which will
affect the order in which the columns are created on dump and reload.
Hm, if column order is important for
Hannu Krosing [EMAIL PROTECTED] writes:
for example - to be consistent, one should also make ALTER TABLE ALTER
COLUMN col SET DEFAULT x change each default value, no ?
er, I think that is in fact a no.
--
greg
---(end of broadcast)---
TIP 2:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
So? They'll get re-merged with the parent column during CREATE TABLE
anyway.
But merged columns that are defined locally still appear in the position they
were defined locally. Not with the other inherited columns.
On Thu, Jun 08, 2006 at 04:44:10PM -0400, Greg Stark wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
for example - to be consistent, one should also make ALTER TABLE ALTER
COLUMN col SET DEFAULT x change each default value, no ?
er, I think that is in fact a no.
Yeah... once a default
On Thu, 2006-06-08 at 16:47 -0400, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
So? They'll get re-merged with the parent column during CREATE TABLE
anyway.
But merged columns that are defined locally still appear in the position
they
Simon Riggs [EMAIL PROTECTED] writes:
Based on the test case Tom shows, I think we need to enforce that ADD
INHERITS will barf if the columns are not in exactly the order they
would have been in if we add done a CREATE ... INHERITS followed by a
DROP INHERITS.
This seems overly strong; if we
Simon Riggs wrote:
Based on the test case Tom shows, I think we need to enforce that ADD
INHERITS will barf if the columns are not in exactly the order they
would have been in if we add done a CREATE ... INHERITS followed by a
DROP INHERITS. That wouldn't be a problem if we just say to people,
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2006-06-08 at 16:47 -0400, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
So? They'll get re-merged with the parent column during CREATE TABLE
anyway.
But merged columns that are defined
I forget whether the developer managed to get it working without doing any
table rewriting. In theory the table just needs to know that records that are
missing that column in the null bitmap should behave as if they have the
default value. But I seem to recall some headaches with that approach.
I've implemented most of ADD/DROP INHERITS but it's my first significant piece
of code at this level. I would appreciate any feedback about it. In particular
I'm worried I may be on the wrong track about how some low level operations
work like memory management, syscache lookups, heap tuple
Greg Stark wrote:
I can send the actual patch to psql-patches, it includes some other changes to
refactor StoreCatalogInheritance and add the syntax to gram.y. But it's still
not quite finished because of default values.
You can send what you've got, and note that it's not for application
Greg Stark [EMAIL PROTECTED] writes:
I've implemented most of ADD/DROP INHERITS but it's my first significant piece
of code at this level. I would appreciate any feedback about it.
I thought we had agreed that the semantics of ADD INHERITS would be to
reject the command if the child wasn't
Tom Lane [EMAIL PROTECTED] writes:
I thought we had agreed that the semantics of ADD INHERITS would be to
reject the command if the child wasn't already suitable to be a child
of the parent. Not to modify it by adding columns or constraints or
whatever. For the proposed uses of ADD
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I thought we had agreed that the semantics of ADD INHERITS would be to
reject the command if the child wasn't already suitable to be a child
of the parent.
I didn't see any discussion like that and I find it pretty
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I thought we had agreed that the semantics of ADD INHERITS would be to
reject the command if the child wasn't already suitable to be a child
of the parent.
I didn't see any
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
In this situation, I think it's entirely reasonable to expect the user
to do any needed ALTER ADD COLUMN, CONSTRAINT, etc commands before
trying to attach a child table to a parent. Having the system do it
for you offers
On Wed, Jun 07, 2006 at 03:33:54PM -0400, Greg Stark wrote:
Perhaps there should be an option when issuing the ADD INHERITS to indicate
whether you want it to create new columns or only match existing columns. That
would also give me a convenient excuse to skip all those NOTICEs about merging
Ühel kenal päeval, K, 2006-06-07 kell 15:33, kirjutas Greg Stark:
Tom Lane [EMAIL PROTECTED] writes:
I thought we had agreed that the semantics of ADD INHERITS would be to
reject the command if the child wasn't already suitable to be a child
of the parent. Not to modify it by adding
How does
ALTER TABLE table INHERITS ADD parent
ALTER TABLE table INHERITS DROP parent
sound?
I'll admit it doesn't read very well but it doesn't necessitate complicating
other rules in gram.y
--
greg
---(end of broadcast)---
TIP 3: Have you
Greg Stark [EMAIL PROTECTED] writes:
How does
ALTER TABLE table INHERITS ADD parent
ALTER TABLE table INHERITS DROP parent
sound?
I'll admit it doesn't read very well but it doesn't necessitate complicating
other rules in gram.y
Or alternatively if people want to keep English-like
Greg Stark said:
Greg Stark [EMAIL PROTECTED] writes:
How does
ALTER TABLE table INHERITS ADD parent
ALTER TABLE table INHERITS DROP parent
sound?
I'll admit it doesn't read very well but it doesn't necessitate
complicating other rules in gram.y
Or alternatively if people want to keep
On Jun 8, 2006, at 9:13 , Greg Stark wrote:
Greg Stark [EMAIL PROTECTED] writes:
How does
ALTER TABLE table INHERITS ADD parent
ALTER TABLE table INHERITS DROP parent
sound?
I'll admit it doesn't read very well but it doesn't necessitate
complicating
other rules in gram.y
Or
Andrew Dunstan [EMAIL PROTECTED] writes:
Greg Stark said:
Or alternatively if people want to keep English-like SQL style grammar:
ALTER TABLE table INHERIT parent
ALTER TABLE table NO INHERIT parent
That could work ... or maybe UNINHERIT would read better than NO INHERIT.
DISINHERIT
grzm,
ALTER TABLE table DISOWN parent?
You can't disown your parents. ;-)
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Greg Stark [EMAIL PROTECTED] writes:
While creating unreserved keywords isn't the end of the world it seems better
to stick to the vocabulary already there if possible. It makes it easier for
the user to remember how to spell commands.
+1. Don't invent new keywords (even if unreserved) when
50 matches
Mail list logo
