Re: Simulating sequences

From: <btober(at)seaworthysys(dot)com>
To: <gearond(at)cvc(dot)net>, <btober(at)seaworthysys(dot)com>, <dustin(at)spy(dot)net>, <pgsql-general(at)postgresql(dot)org>, <paulo(dot)pizarro(at)digitro(dot)com(dot)br>
Subject: Re: Simulating sequences
Date: 2003-08-19 17:10:05
Message-ID: 51399.12.111.55.140.1061313005.squirrel@$HOSTNAME
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> so has the final implemention become:
> A/ A column value per employee

Almost. More precisely, it is, as you would expect, one ROW per employee
(in the employee table). The employee table includes a COLUMN defined to
store the most-recently-issued number in the sequence for that paricular
employee.

> B/ A trigger to implement the incrementing of the value

Yes. When an expense report is created for an employee, i.e., a row is
inserted in the expense_report table, that trigger fires, updating the
employee's sequence column value and using that new value in the
expense_report table.

> C/ A row/record lock to enforce atomicity

The lock is not explicite. I'm told from good sources that the UPDATE
statement creates a lock implicitely in the updated row, and that there
is an implicite transaction around the trigger as part of the originating
INSERT statement.

>
> btober(at)seaworthysys(dot)com wrote:
>
>>>On Monday, Aug 18, 2003, at 09:01 US/Pacific,
>>> <btober(at)seaworthysys(dot)com>
>>> wrote:
>>>
>>>
>>>>With those items in mind, your function could become:
>>>>
>>>>CREATE FUNCTION key_generation(integer, varchar(20)) RETURNS integer
>>>> AS'
>>>>DECLARE
>>>> the_department ALIAS FOR $1;
>>>> the_table_name ALIAS FOR $2;
>>>>BEGIN
>>>> IF NOT EXISTS(SELECT 1 FROM cnfg_key_generation
>>>> WHERE the_department = department AND the_table_name =
>>>>table_name)
>>>>THEN
>>>> INSERT INTO cnfg_key_generation VALUES
>>>>(the_department,the_table_name,0);
>>>> END IF;
>>>
>>> I would get the insert out of there, too. If it doesn't exist,
>>> throw
>>>an exception. I don't believe sequences should automatically create
>>> themselves (the tables and columns don't).
>>>
>>
>>
>> I agree. In my own case I need a sequence for each employee, and the
>> simulated sequence is defined as a column in the employee table, so
>> I'm guaranteed to have a a place to do the incrementing when the need
>> arises. Also, I used a "DEFAULT 0" clause on the column definition
>> for the sequence value, rather than explicitly inserting a zero. I
>> left the insert statement in place for compatibility with the
>> original inquirer's definition.
>>

~Berend Tober

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jan Wieck 2003-08-19 17:12:26 Re: Simulating sequences
Previous Message Jeffrey Melloy 2003-08-19 17:07:57 Re: Grouping by date range