Thread: select regexp_matches('a a a', '([a-z]) a','g');
First: Please don't reply to an existing message to create a new thread.
Your mail client copies the replied-to message ID into the References:
header, and well-implemented mail clients will thread your message under
a now-unrelated thread.
Compose a new message instead.
Marc Mamin wrote:
> I have a string that contains a serie of chars, separated by single
> spaces.
>
> e.g 'a b x n r a b c b'
>
> Having such a string, I d'like to get a list of all predecessors of a
> given character.
> In the example, the predecessors of b are a,a,c.
OK, so wherever `b' occurs, you want the character at index `b -2'.
> select regexp_matches('a a a', '([a-z]) a','g');
> => {"a "} only
The issue is that regular expressions don't like to overlap matches. The
first match consumes _two_ leading `a' characters.
What you need is a zero-width lookahead assertion, available in
Perl-style extended regular expressions. Handily, recent PostgreSQL
versions support these, so you can write:
test=> select regexp_matches( 'a a a', '([a-z]) (?=a)', 'g');regexp_matches
----------------{a}{a}
(2 rows)
--
Craig Ringer
Hello, I have two databases db1 and db2 with the same database structure on different systems with no network connection. In the first system with the db1 database user updates the master data. At the end of every day, the user needs to take the backup of updated data of master tables on db1 and update the data on another system with db2 database. We can't use WAL as in this as we want to take incremental backup of few tables only and can't use slony as there is no network connection between the systems. Please suggest some solution. Thanks, Jyoti
Wow, I'm impressed. Let me quote part of the message you just replied to with a TOTALLY UNRELATED NEW THREAD: "First: Please don't reply to an existing message to create a new thread. Your mail client copies the replied-to message ID into the References: header, and well-implemented mail clients will thread your message under a now-unrelated thread. Compose a new message instead." -- Craig Ringer
Craig Ringer wrote: ... something kinda rude, in retrospect. Sorry. Unpleasantness is going around in my immediate environment, and I'm apparently prickly and grumpy. -- Craig Ringer
Jyoti Seth wrote: > Hello, > > I have two databases db1 and db2 with the same database structure on > different systems with no network connection. In the first system with the > db1 database user updates the master data. At the end of every day, the user > needs to take the backup of updated data of master tables on db1 and update > the data on another system with db2 database. > > We can't use WAL as in this as we want to take incremental backup of few > tables only and can't use slony as there is no network connection between > the systems. > > Please suggest some solution. > > Thanks, > Jyoti > > I guess you are triyng to avoid the 'pg_dump - save_to_floppy - walk_to_db2_place - pg_restore' pattern. Well, can you save `pg_dump' in some middle place? One place which machine1 and machine2 have access to? If so, you can kind of automate the job using two programs, one (in the master) who 'upload' (via ftp maybe, scp or whatever) in this middle place, ando other in the slave who 'download' and process the file using pg_restore. HTH Gerardo
On 2009-05-08, Jyoti Seth <jyotiseth2001@gmail.com> wrote: > Hello, > > I have two databases db1 and db2 with the same database structure on > different systems with no network connection. In the first system with the > db1 database user updates the master data. At the end of every day, the user > needs to take the backup of updated data of master tables on db1 and update > the data on another system with db2 database. > > We can't use WAL as in this as we want to take incremental backup of few > tables only and can't use slony as there is no network connection between > the systems. > > Please suggest some solution. some sort of diff? dump the tables you are interested in in a known order (perhaps use "copy from select .... order by .... " ) compare it with yesterdays ship the differences. dump the table at the remote end apply the patch truncate the table and load the patched version.