Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] regular expressions from hell

From: ocie(at)paracel(dot)com
To: brett(at)work(dot)chicken(dot)org (Brett McCormick)
Cc: maillist(at)candle(dot)pha(dot)pa(dot)us, dg(at)illustra(dot)com, pgsql-hackers(at)hub(dot)org, pgsql-questions(at)hub(dot)org
Subject: Re: [HACKERS] regular expressions from hell
Date: 1998-06-01 21:41:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Brett McCormick wrote:
> On Mon, 1 June 1998, at 10:16:35, Bruce Momjian wrote:
> > > Ok, my vote is to build regexes into the pgsql binary or into a .so that
> > > we distribute. There should be no need to have perl installed on a system
> > > to run postgresql. If we are going to extend the language to improve on
> > > the very lame sql92 like clause, we need to have it be part of the system
> > > that can be counted on, not something you might or might not have depending
> > > on what else is installed.
> I'm not suggesting we require perl to be installed to run postgres, or
> replace the current regexp implementation with perl.  i was just
> lamenting the fact that there are no less than 10 different regexp
> implementations, with different metacharacters.  why should I have to
> remember one syntax when I use perl, one for sed, one for emacs, and
> another for postgresql?  this isn't a problem with postgres per se,
> just the fact that there seems to be no standard.

I think most of this is due to different decisions on what needs to be
escaped or not.  For instance, if memory serves, GNU grep treats
parens as metacharacters, which must be escaped with a backslash to
match parens, while in Emacs, parens match parens and must be escaped
to get their meta-character meaning.  Things have gone too far to have
one standard now I'm afraid.


In response to


pgsql-hackers by date

Next:From: David GouldDate: 1998-06-01 22:43:54
Subject: Re: [HACKERS] custom types and optimization
Previous:From: ocieDate: 1998-06-01 21:32:17
Subject: Re: [HACKERS] Query cancel and OOB data (fwd)

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group