Обсуждение: Re: [QUESTIONS] Re: [HACKERS] text should be a blob field

-----Original Message-----
From: Peter T Mount <psqlhack@maidast.demon.co.uk>
To: Jan Wieck <jwieck@debis.com>
Cc: Bruce Momjian <maillist@candle.pha.pa.us>;
Andreas.Zeugswetter@telecom.at <Andreas.Zeugswetter@telecom.at>;
pgsql-hackers@hub.org <pgsql-hackers@hub.org>
Date: zondag 15 maart 1998 21:10
Subject: Re: [QUESTIONS] Re: [HACKERS] text should be a blob field


>On Wed, 4 Mar 1998, Jan Wieck wrote:
>
>> Bruce wrote:
>>
>> > > 1. Is there a call made by the backend to each datatype when a row is
>> > >    deleted? I can't see one.
>> >
>> > Well, you could have a RULE that deletes the large object at row
>> > deletion time.  However, if two rows point to the same large object,
the
>> > first one deleting it would delete the large object for the other.  The
>> > only solution to this is to have a separate large object table, and use
>> > reference counts so only the last user of the object deletes it.
>>
>>     I think triggers are more appropriate.
>>
>>     On INSERT check that the large object referenced exists.
>>
>>     On  UPDATE  if large object reference changes, check that new
>>     large object exists and  check  if  old  large  object  isn't
>>     referenced  any more in which case drop the old large object.
>>
>>     On DELETE check if large object isn't referenced any more ...
>>
>>     Yes - I like triggers :-)
>
>I'm begining to agree with you here.
>
>So far, I've got the trigger to work, so if a row of a table is deleted,
>or an oid referencing a BLOB is updated, then the old BLOB is deleted.
>This removes the orphaned BLOB problem.
>
>The only problem I have now, is:
>
>  How to get a trigger to be automatically created on a table when the
>  table is created. This would be required, so the end user doesn't have
>  to do this (normally from within an application).
>
>This would be required, esp. for expanding the text type (or memo, or
>whatever).
>


Since triggers are not inherited this doesn't seem appropiate too me -:(.
Won't user have to do some magic on inherited tables?

I think many things will be fixed when triggers, indices etc. are inherited
properly by derived classes.

With regards from,
Maurice.

> Since triggers are not inherited this doesn't seem appropiate to me
> -:(. Won't user have to do some magic on inherited tables?
>
> I think many things will be fixed when triggers, indices etc. are
> inherited properly by derived classes.

This is an interesting point. We have perhaps been neglecting to discuss
how inheritance should behave with new features. Certainly at least some
things (like default values and constraints) do inherit as you would
expect. It's not clear to me that inheriting indices is appropriate,
since indices are basically just an artifact for performance
improvement; the results of a query do not change with the presence of
an index. Also, if a table is inherited, then the access pattern of the
resulting table might be different, requiring a different index anyway.

I haven't worked with triggers; what is their current behavior with
inheritance? Maurice implies that they are not inherited at all. If not,
should they be?

                     - Tom