On 3/17/07, louis gonzales <[EMAIL PROTECTED]> wrote:
Statement-level triggers follow simple visibility rules: none of the changes
made by a statement are visible to statement-level triggers that are invoked
before the statement, whereas all modifications are visible to
statement-level after trig
louis gonzales escribió:
> louis gonzales wrote:
>
> >2) Seeing as you have no idea - not attacking, stating fact - on the
> >rationale behind the "insert statement-level" to create 1-to-1 table
> >for each statement-level
> >insert, I'd say your presumption is unfounded.
This won't work anyway
louis gonzales wrote:
Dear Hubert,
Two things
1) _*"statement-level" and "row-level" straight from PostgreSQL:
http://www.postgresql.org/docs/8.1/interactive/trigger-datachanges.html*_
*
_*Statement-level triggers*_ follow simple visibility rules:
none of the changes made by a
Dear Hubert,
Two things
1) "statement-level" and "row-level" straight from PostgreSQL:
http://www.postgresql.org/docs/8.1/interactive/trigger-datachanges.html
Statement-level triggers follow simple visibility
rules: none of the changes made by a statement are visible to
statement-level
On 3/16/07, louis gonzales <[EMAIL PROTECTED]> wrote:
I want to write a statement-level trigger - one that happens once per
statement - such that, immediately after an insert into a table(which
gets a unique integer value as an ID from a defined sequence, being the
primary key on the table), a ne
louis gonzales wrote:
Is it better to have 1 monolithic table and have to search it, or
small individual tables but many of them?
Ron Johnson wrote:
Yes, 1 large table. This is what RDMS were designed for.
---(end of broadcast)---
TIP 1: if p
louis gonzales wrote:
> Actually, there will be creation of 2 new tables for each insert on
> 'primary' table, so for 10K records, we would have 20K tables. Those
> tables each will never grow more than a few records each.
>
> Is it better to have 1 monolithic table and have to search it, or smal
Actually, there will be creation of 2 new tables for each insert on
'primary' table, so for 10K records, we would have 20K tables. Those
tables each will never grow more than a few records each.
Is it better to have 1 monolithic table and have to search it, or small
individual tables but many
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/15/07 22:14, louis gonzales wrote:
> Hello List,
> I want to write a statement-level trigger - one that happens once per
> statement - such that, immediately after an insert into a table(which
> gets a unique integer value as an ID from a defined
Hey Joshua,
I appreciate the insight. That's clear.
Thanks again,
Joshua D. Drake wrote:
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
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
:) , 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 so
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... ]
Hello List,
I want to write a statement-level trigger - one that happens once per
statement - such that, immediately after an insert into a table(which
gets a unique integer value as an ID from a defined sequence, being the
primary key on the table), a new table is created with foreign key
con
14 matches
Mail list logo
