Hi again. Tom wrote:
> Um ... I don't see anything about RecipeNumericParameterSnapshot here.
Grr... I meant to put:
Reports=# \d "RecipeNumericParameterSnapshot"
Table "public.RecipeNumericParameterSnapshot"
Column | Type | Modifiers
------------------+------------------------+-----------------------
Name | character varying(255) | not null
RecipeSnapshotID | integer | not null
Alias | character varying(255) | not null
Description | text |
IsOptional | boolean | not null
Direction | integer | not null
HostExposed | boolean | not null default true
Units | character varying(255) | not null
DefaultValue | double precision | not null
BoundaryType | integer | not null
Boundary | double precision[] |
Indexes: "RecipeNumericParameterSnapshot_pkey" PRIMARY KEY, btree
("Name", "RecipeSnapshotID")
Foreign-key constraints:
"RecipeNumericParameterSnapshot_RecipeSnapshot_fk" FOREIGN KEY
("RecipeSnapshotID") REFERENCES "RecipeSnapshot"("ID") ON DELETE CASCADE
DEFERRABLE INITIALLY DEFERRED
Inherits: "RecipeParameterSnapshot"
> Are they *referenced* by other tables' foreign keys? But in any case,
> the issue isn't about ALTER TABLE in itself, it's that some preceding
> uncommitted operation had left some trigger events (read: FK
> conditions that need to be verified). Doesn't matter which columns
> those might be on.
Hmm, that makes more sense. None of these columns are referenced by
someone else, but it's possible that some foreign key is being
referenced or handled earlier in the transaction. I'll look in that
direction; thanks!
Reuven
--
Reuven M. Lerner -- Web development, consulting, and training
Mobile: +972-54-496-8405 * US phone: 847-230-9795
Skype/AIM: reuvenlerner
