Re: [HACKERS] RULE (and ALTER TABLE) questions

From: jwieck(at)debis(dot)com (Jan Wieck)
To: hannu(at)trust(dot)ee (Hannu Krosing)
Cc: jwieck(at)debis(dot)com, pgsql-hackers(at)postgreSQL(dot)org, maillist(at)remo(dot)demon(dot)co(dot)uk, pgsql-sql(at)postgreSQL(dot)org
Subject: Re: [HACKERS] RULE (and ALTER TABLE) questions
Date: 1999-02-12 19:16:57
Message-ID: m10BO5B-000EBRC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql

> But when doing that at the table creation time, then the table can
> actually
> be defined as a view on storage table and rules for insert update and
> delete
> be defined for this view that do the actual data manipulation on the
> storage table.

That's IMHO a too specific case to do it generally with the
rule system. Should be some kind of constraint handled by
the parser in putting an UPPER() func node around the
targetlist expression.

There could be more general support implemented, in that a
user can allways tell that a custom function should be called
with the result of the TLE-expr before the value is dropped
into the tuple on INSERT/UPDATE.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ken Mort 1999-02-13 04:11:48 8K block limit
Previous Message Hannu Krosing 1999-02-12 17:09:41 Re: [HACKERS] RULE (and ALTER TABLE) questions

Browse pgsql-sql by date

  From Date Subject
Next Message Paul Ramsey 1999-02-12 21:33:08 Booleans and Casting
Previous Message Hannu Krosing 1999-02-12 17:09:41 Re: [HACKERS] RULE (and ALTER TABLE) questions