Thread: Extending Regular Expression bounds limit of 255.
In the docs <a href="http://www.postgresql.org/docs/8.3/interactive/functions-matching.html#POSIX-EMBEDDED-OPTIONS-TABLE">http://www.postgresql.org/docs/8.3/interactive/functions-matching.html#POSIX-EMBEDDED-OPTIONS-TABLE</a><br />it says that Regular Expression bounds {m,n} that m and n can be 0-255. Is there a way to extend the upper limit. Weare trying to be consistent between Regular Expressionimplementation an the other implementations do not have this limit.<br/><br clear="all" />Brent DeSpain<br />Schweitzer Engineering Laboratories, Inc.<br />
On 28 May 2010 07:33, Brent DeSpain <bd.postgres@gmail.com> wrote: > In the docs > http://www.postgresql.org/docs/8.3/interactive/functions-matching.html#POSIX-EMBEDDED-OPTIONS-TABLE > it says that Regular Expression bounds {m,n} that m and n can be 0-255. Is > there a way to extend the upper limit. We are trying to be consistent > between Regular Expressionimplementation an the other implementations do not > have this limit. Interesting. The POSIX standard for REs dictates this limit; which implementations you're using don't adhere to it? Cheers, Andrej -- Please don't top post, and don't use HTML e-Mail :} Make your quotes concise. http://www.american.edu/econ/notes/htmlmail.htm
No. Strangely enough they don't in enforce this limit.<br /><br clear="all" />Brent DeSpain<br />Schweitzer EngineeringLaboratories, Inc.<br /><br /><br /><div class="gmail_quote">On Thu, May 27, 2010 at 2:59 PM, Andrej <span dir="ltr"><<ahref="mailto:andrej.groups@gmail.com">andrej.groups@gmail.com</a>></span> wrote:<br /><blockquote class="gmail_quote"style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><divclass="im">On 28 May 2010 07:33, Brent DeSpain <<a href="mailto:bd.postgres@gmail.com">bd.postgres@gmail.com</a>>wrote:<br /> > In the docs<br /> > <a href="http://www.postgresql.org/docs/8.3/interactive/functions-matching.html#POSIX-EMBEDDED-OPTIONS-TABLE" target="_blank">http://www.postgresql.org/docs/8.3/interactive/functions-matching.html#POSIX-EMBEDDED-OPTIONS-TABLE</a><br />> it says that Regular Expression bounds {m,n} that m and n can be 0-255. Is<br /> > there a way to extend the upperlimit. We are trying to be consistent<br /> > between Regular Expressionimplementation an the other implementationsdo not<br /> > have this limit.<br /></div>Interesting. The POSIX standard for REs dictates this limit;which<br /> implementations<br /> you're using don't adhere to it?<br /><br /><br /> Cheers,<br /> Andrej<br /><fontcolor="#888888"><br /><br /><br /><br /> --<br /> Please don't top post, and don't use HTML e-Mail :} Make your quotesconcise.<br /><br /><a href="http://www.american.edu/econ/notes/htmlmail.htm" target="_blank">http://www.american.edu/econ/notes/htmlmail.htm</a><br/></font></blockquote></div><br />
It looks like most of our tools are using the Perl version of regular expressions with an upper limit of a bound being 32766. Is there any way to change this in PG? Or can I change from POSIX to Perl?
Brent DeSpain
Schweitzer Engineering Laboratories, Inc.
Brent DeSpain
Schweitzer Engineering Laboratories, Inc.
On Thu, May 27, 2010 at 4:44 PM, Brent DeSpain <bd.postgres@gmail.com> wrote:
No. Strangely enough they don't in enforce this limit.
Brent DeSpain
Schweitzer Engineering Laboratories, Inc.On Thu, May 27, 2010 at 2:59 PM, Andrej <andrej.groups@gmail.com> wrote:On 28 May 2010 07:33, Brent DeSpain <bd.postgres@gmail.com> wrote:Interesting. The POSIX standard for REs dictates this limit; which
> In the docs
> http://www.postgresql.org/docs/8.3/interactive/functions-matching.html#POSIX-EMBEDDED-OPTIONS-TABLE
> it says that Regular Expression bounds {m,n} that m and n can be 0-255. Is
> there a way to extend the upper limit. We are trying to be consistent
> between Regular Expressionimplementation an the other implementations do not
> have this limit.
implementations
you're using don't adhere to it?
Cheers,
Andrej
--
Please don't top post, and don't use HTML e-Mail :} Make your quotes concise.
http://www.american.edu/econ/notes/htmlmail.htm
Excerpts from Brent DeSpain's message of jue may 27 18:55:55 -0400 2010: > It looks like most of our tools are using the Perl version of regular > expressions with an upper limit of a bound being 32766. Is there any way to > change this in PG? Or can I change from POSIX to Perl? See regcomp.c; you'll have to recompile. The interesting constant is DUPMAX (defined in regguts.h as per POSIX), but note that there's arithmetic in repeat() with those values. I wouldn't recommend doing any of this unless you have time to figure out whether the algorithms are efficient for larger values though. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Yep. That is what I was looking at this morning. It is probably too late in this release of our project to make this change.<br/><br />Thanks for the help.<br /><br clear="all" />Brent DeSpain<br />Schweitzer Engineering Laboratories, Inc.<br/><br /><br /><div class="gmail_quote">On Fri, May 28, 2010 at 9:14 AM, alvherre <span dir="ltr"><<a href="mailto:alvherre@commandprompt.com">alvherre@commandprompt.com</a>></span>wrote:<br /><blockquote class="gmail_quote"style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Excerptsfrom Brent DeSpain's message of jue may 27 18:55:55 -0400 2010:<br /><div class="im">> It looks like most of ourtools are using the Perl version of regular<br /> > expressions with an upper limit of a bound being 32766. Is thereany way to<br /> > change this in PG? Or can I change from POSIX to Perl?<br /><br /></div>See regcomp.c; you'llhave to recompile. The interesting constant is<br /> DUPMAX (defined in regguts.h as per POSIX), but note that there's<br/> arithmetic in repeat() with those values. I wouldn't recommend doing<br /> any of this unless you have timeto figure out whether the algorithms<br /> are efficient for larger values though.<br /><font color="#888888"><br />--<br /> Álvaro Herrera <<a href="mailto:alvherre@commandprompt.com">alvherre@commandprompt.com</a>><br /> The PostgreSQLCompany - Command Prompt, Inc.<br /> PostgreSQL Replication, Consulting, Custom Development, 24x7 support<br /></font></blockquote></div><br/>
On 2010-05-27, Brent DeSpain <bd.postgres@gmail.com> wrote: > --00504502c13812967604879b4ba3 > Content-Type: text/plain; charset=ISO-8859-1 > > It looks like most of our tools are using the Perl version of regular > expressions with an upper limit of a bound being 32766. Is there any way to > change this in PG? Or can I change from POSIX to Perl? perhaps you can do something in pl-perl? posix regular expressions are different to perl regular expressions in several ways.
Jasen Betts <jasen@xnet.co.nz> wrote: >> It looks like most of our tools are using the Perl version of regular >> expressions with an upper limit of a bound being 32766. Is there any way to >> change this in PG? Or can I change from POSIX to Perl? > perhaps you can do something in pl-perl? > posix regular expressions are different to perl regular expressions in > several ways. Another last resort possibility would of course be to "pre- compile" the regular expressions from "A{2000}" to "A{255}A{255}A{255}A{255}A{255}A{255}A{255}A{215}" (with the headaches of "A{1000,2000}" left as an exercise to the read- er :-)). Tim
On 2010-05-29, Tim Landscheidt <tim@tim-landscheidt.de> wrote: > Jasen Betts <jasen@xnet.co.nz> wrote: > >>> It looks like most of our tools are using the Perl version of regular >>> expressions with an upper limit of a bound being 32766. Is there any way to >>> change this in PG? Or can I change from POSIX to Perl? > >> perhaps you can do something in pl-perl? > >> posix regular expressions are different to perl regular expressions in >> several ways. > > Another last resort possibility would of course be to "pre- > compile" the regular expressions from "A{2000}" to > "A{255}A{255}A{255}A{255}A{255}A{255}A{255}A{215}" (A{200}){10}might work better. > (with the headaches of "A{1000,2000}" left as an exercise to the read- > er :-)). easy enoungh to write, but probably easy to write an expression with factorial complexity too, but this one should work, having at worst two ways of matching any string. (A{200}){5,9}A{0,200} but (A{5,10}){200} is asking for trouble.