Re: Problem with Trigger

"Don Mies (NIM)" <dmies@networksinmotion.com> writes:
> What I'm trying to accomplish is to truncate some input strings if they
> are larger than the defined column in our database.

This cannot work because the value gets put into the tuple --- and hence
cast to the defined column type --- before the trigger can ever fire.

If you wanted to define the column as just "text", and put 100% reliance
on the trigger to enforce the length limit, then it would work.

> 3.    Since the columns that I need to do this to are all somewhat
> controlled (i.e. They will never be extremely large, I just don't know
> exactly how large.) would it be reasonable to just redefine them as
> "varchar" or "text" with no upper limit?

Probably.  I think the standard's focus on "varchar(N)" is a hangover
from the days of 80-column punched cards.  In almost every modern-day
app, whatever value they're using for N is just picked out of the air
and has no business-logic justification whatsoever.  Unless you can
point to a concrete application-driven reason why you need a limit of
exactly N, I think you should be using text.

> 4.    If I could make the above code work, it would be highly
> desireable to write only 1 function that could be called from multiple
> triggers.

Not going to happen in plpgsql --- it has no real support for
run-time-determined column names.  You could make it work in one of the
other PLs.  I still question the need for it at all, though.

            regards, tom lane