Added to TODO:
* Allow AFTER triggers on system tables
---
Gavin Sherry wrote:
> On Thu, 12 Feb 2004, Tom Lane wrote:
>
> > Gavin Sherry <[EMAIL PROTECTED]> writes:
> > > Do you have an example at hand of a system
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Do you have an example at hand of a system function which will face this
> problem so that I can see what is involved?
Mmm ... try CREATE TABLE with foreign keys. IIRC the basic table is
created and then we do ALTER TABLE ADD FOREIGN KEY.
On Thu, 12 Feb 2004, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > Do you have an example at hand of a system function which will face this
> > problem so that I can see what is involved?
>
> Mmm ... try CREATE TABLE with foreign keys. IIRC the basic table is
> created and then w
On Wed, 11 Feb 2004, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > My idea is to provide a generic interface which is called inside
> > ProcessUtility() after all other functions are called for the particular
> > node we're handling. The nodetag itself will be passed to this gener
Rod Taylor <[EMAIL PROTECTED]> writes:
> Yes, the internal calls from one command to another make this tricky --
> but the return Tag is set very early for the statement. Could the Before
> trigger for system commands (CREATE, ALTER, etc.) not be kicked of in
> the same area as the tag is set?
At
Gavin Sherry <[EMAIL PROTECTED]> writes:
> My idea is to provide a generic interface which is called inside
> ProcessUtility() after all other functions are called for the particular
> node we're handling. The nodetag itself will be passed to this generic
> function, the function will map nodetag t
On Wed, 2004-02-11 at 22:30, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > There have been a few discussions about triggers on system tables in
> > the past and the problems with such triggers seem to be:
>
> I think the killer problem is that we couldn't allow triggers on system
On Wed, 11 Feb 2004, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > There have been a few discussions about triggers on system tables in
> > the past and the problems with such triggers seem to be:
>
> I think the killer problem is that we couldn't allow triggers on system
> tables
Gavin Sherry <[EMAIL PROTECTED]> writes:
> There have been a few discussions about triggers on system tables in
> the past and the problems with such triggers seem to be:
I think the killer problem is that we couldn't allow triggers on system
tables to do very much. By definition, the database is
On Thu, 12 Feb 2004, Gavin Sherry wrote:
> Hi all,
>
> I've been thinking about triggers on system tables. The motivation for
> this is to allow for better interaction between the system and interfaces.
> For example, interfaces could store database meta data (list of tables)
> and have the cache
Hi all,
I've been thinking about triggers on system tables. The motivation for
this is to allow for better interaction between the system and interfaces.
For example, interfaces could store database meta data (list of tables)
and have the cache invalidated by a trigger on pg_class (calling a
funct
11 matches
Mail list logo
