Обсуждение: String functions like split() and join() in plpgsql

Hi,

I'm writing a trigger to change the third field in a varchar record. (it's
an SOA field from DNS) and I can do it in plperl but since it needs to be a
trigger I have to do it in plpgsql (or other right?).

In perl it's as simple as:
// assuming $soa = 'ns1.domain.com hostmaster.domain.com 104249825 10800
3600 604000 86400';
@x =  split(/ /, $soa); $x[2] = time(); join(' ', @x);

Any ideas on how I can create a trigger to change the third field to now()?

Can I use perl as a trigger?

Thanks in advance,
davidu

--
"Never doubt that a small group of thoughtful citizens can change the
world. Indeed, it is the only thing that ever has." --Margaret Mead

"David U." <davidu@everydns.net> writes:
> I'm writing a trigger to change the third field in a varchar record. (it's
> an SOA field from DNS) and I can do it in plperl but since it needs to be a
> trigger I have to do it in plpgsql (or other right?).

There's nothing to stop you from calling a plperl function from a
plpgsql trigger function.  If you've got complicated string-mashing
requirements, I'd certainly recommend coding them in plperl (or pltcl).

Someday someone should get around to implementing trigger support for
plperl, but in the meantime a two-layer approach seems like your answer.

            regards, tom lane

Or try plpython.  You can write triggers in plpython directly.

--elein

On Monday 13 January 2003 18:39, Tom Lane wrote:
> "David U." <davidu@everydns.net> writes:
> > I'm writing a trigger to change the third field in a varchar record.
> > (it's an SOA field from DNS) and I can do it in plperl but since it needs
> > to be a trigger I have to do it in plpgsql (or other right?).
>
> There's nothing to stop you from calling a plperl function from a
> plpgsql trigger function.  If you've got complicated string-mashing
> requirements, I'd certainly recommend coding them in plperl (or pltcl).
>
> Someday someone should get around to implementing trigger support for
> plperl, but in the meantime a two-layer approach seems like your answer.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

--
----------------------------------------------------------------------------------------
elein@varlena.com     Database Consulting     www.varlena.com
              I have always depended on the [QA] of strangers.