Re: [SQL] idea for a geographically distributed database: how best to implement?

David Bath wrote: > There are a couple of philosophical perspectives I've come across in > previous > work with cadastral data that may be useful...[snipped] Thanks, David In this particular application, structures such as postcode sectors, administrative boundaries etc. are not really of much i

Re: [SQL] Is it possible to redirect an update/insert/delete to a different table?

>Try it. [snipped example] Ah. Basically, you set up the rule to assign every column, and if the update doesn't redefine some columns, then it still works. I didn't understand that you could get the rule to work generically like this. I'll presume that the rule will need amending if the table col

Re: [SQL] Is it possible to redirect an update/insert/delete to a different table?

rules, but it may not be the case. Thanks! Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Kretschmer Sent: 20 November 2005 16:17 To: pgsql-sql@postgresql.org Subject: Re: [SQL] Is it possible to redirect an update/insert/delete to

Re: [SQL] Is it possible to redirect an update/insert/delete to a different table?

ransparently update the pears table with whatever values happened to be defined by the original update command? Is there a special keyword that I've missed? Regards, Andy Ballingall -Original Message- From: Jaime Casanova [mailto:[EMAIL PROTECTED] Sent: 20 November 2005 14:23 To: [EMAIL

Re: [SQL] Is it possible to redirect an update/insert/delete to a different table?

ied to pears instead? Thanks, Andy ----- Andy Ballingall wrote: > I've looked through rules, and as far as I can make out, they are > only useful for explicit actions. I'm looking for something that > behaves as though it simply substitutes the table name for a > different ta

[SQL] Is it possible to redirect an update/insert/delete to a different table?

it simply substitutes the table name for a different table name before executing the command, no matter what the command looks like.   Thanks Andy Ballingall

[SQL] idea for a geographically distributed database: how best to implement?

if I can distribute my application over large numbers of small servers, I’ll end up with more bangs for the buck, and it’ll be much easier to manage growth by managing the number of servers, and number of cells hosted on each server.   Thanks for any suggestions! Andy Ballingall   'pgsq

Re: [SQL] idea for a geographically distributed database: how best to implement?

ill always go to the "local" table, which Slony "replicates" out to the neighbouring nodes. And when selecting on it (the "complete" table), you get data from your local table, and any "replicated" neighbouring node's tables which are in the local schema

Re: [SQL] idea for a geographically distributed database: how best

ed to say it). Thanks, Andy > > > > > "Andy Ballingall" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > Hello, > > > > I've got a database for a website which is a variant of the 'show stuff > > near > &g

Re: [SQL] idea for a geographically distributed database: how best to implement?

Unlike many data sets, mine is almost totally partitioned geographically. There is only *one* little detail - that of visibility of data in neighbouring cells, and that is sorted out with my idea of duplicating information between neighbours. Hope that fills in some gaps... Thanks for your c

[SQL] idea for a geographically distributed database: how best to implement?

scheme is that if I can distribute my application over large numbers of small servers, I'll end up with more bangs for the buck, and it'll be much easier to manage growth by managing the number of servers, and number of cells hosted on each server. Thanks for any suggestion