:) , something that is analogous to a race condition. is this something
I shouldn't be concerned with?
I suppose if I knew for certain there was some kind of synchronous
behavior, then I wouldn't fear a potentially subsequent event completing
before the previous one doing so.
As a possible solution, I'm thinking that I can make the trigger be a
before trigger, where the before trigger captures the 'nextvalue' for
both the actual insert and the table creation would be based on this,
while incrementing the sequence to guarantee that each successive pull
on the nextvalue will have the correct one.
Does that sound plausible?
Thanks,
Tom Lane wrote:
louis gonzales <[EMAIL PROTECTED]> writes:
As an example:
insertX which initiates the trigger reads the 'nextvalue' from the
sequence and begins to create the associcated table
insertY happens almost at the same time, so that it gets the same
'nextvalue' from the sequence
[ blink... ] Whatever makes you think that could happen?
regards, tom lane
--
Email: [EMAIL PROTECTED]
WebSite: http://www.linuxlouis.net
"Open the pod bay doors HAL!" -2001: A Space Odyssey
"Good morning starshine, the Earth says hello." -Willy Wonka
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
