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 colu
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.
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 colu
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, if
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; i
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 positio
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... onc
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 col
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)---
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
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
Ü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 COLU
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?
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 yo
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
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 w
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
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
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
> > dependenci
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
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 wan
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.
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
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_
"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 ye
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* annoy
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 t
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 defa
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 ent
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 suppor
Ü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 e
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 dele
"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
> > > 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:
>
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) wh
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
"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 INHER
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 alterna
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
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 Engl
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 c
Ü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 ad
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
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
>> fo
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
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 p
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 IN
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 a
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
y
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 creati
50 matches
Mail list logo
