On Wed, Aug 24, 2011 at 8:28 AM, Guillaume Lelarge
wrote:
> There's not much we can do about this. The SELECT part is retrieved via
> a call to pg_getviewdef. So, if you want to call this a bug, this is a
> PostgreSQL bug (and I don't think this is).
I agree that its probably not a bug, but it i
I ran into this warning when we switched from one version of Postgres to
another.
It complains when the view is created, but it works fine when I select from
it.
But I don't mix E' and \\
My views have strings like '\\.[0-9]+\\.'
Your view has both E' and \\ -- could it be that if you have E' y
On Wed, 2011-08-24 at 08:04 -0700, Richard Broersma wrote:
> On Tue, Aug 23, 2011 at 11:18 PM, Guillaume Lelarge
> wrote:
> > It would be great if you could provide us a complete example.
>
> Here is a sample view.
>
> --*
> CREATE VIEW TestView AS select cmpnt_name, regexp_matches(c
On Tue, Aug 23, 2011 at 11:18 PM, Guillaume Lelarge
wrote:
> It would be great if you could provide us a complete example.
Here is a sample view.
--*
CREATE VIEW TestView AS select cmpnt_name, regexp_matches(cmpnt_name,
E'(^\\d{1,2})-([A-Z]+) *- ?(\\d{3,4})-?([A-Z]*)?') from compone
On Tue, 2011-08-23 at 14:28 -0700, Richard Broersma wrote:
> I expect many have experienced this before.
>
> Views->Create Script does not prefix regular expressions strings with
> E. (e.g. E'\\d'). -- does this have something to do with
> "standard_conforming_strings = on"?
>
> So each time a v
I expect many have experienced this before.
Views->Create Script does not prefix regular expressions strings with
E. (e.g. E'\\d'). -- does this have something to do with
"standard_conforming_strings = on"?
So each time a view is tinkered with, the user must find all
occurrences of the regular e
