feature request

Lists: pgsql-hackers
From: "Omar Bettin" <o(dot)bettin(at)informaticaindustriale(dot)it>
To: <pgsql-hackers(at)postgresql(dot)org>
Subject: feature request
Date: 2010-02-25 21:35:52
Message-ID: C549ABEA3D4B4ABEA7EBC231E7AEBC43@fly01
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

hello to everyone,
is a bit late for an italian, but after an long day debugging I had an idea.
Why not introduce a special SQL command like
STORE WHERE [condition] FROM [table]
removing all data that meet the condition and storing them into another database?
Then, if a query that needs the stored data is executed after such command the database joins the stored data into the result query.
This can keep the production database lightweight and fast.
Regards

Omar Bettin


From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Omar Bettin <o(dot)bettin(at)informaticaindustriale(dot)it>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: feature request
Date: 2010-02-25 22:11:11
Message-ID: 603c8f071002251411r2de0426chf8b89f0db4b09b14@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Feb 25, 2010 at 4:35 PM, Omar Bettin
<o(dot)bettin(at)informaticaindustriale(dot)it> wrote:
> hello to everyone,
> is a bit late for an italian, but after an long day debugging I had an idea.
> Why not introduce a special SQL command like
> STORE WHERE [condition] FROM [table]
> removing all data that meet the condition and storing them into another
> database?
> Then, if a query that needs the stored data is executed after such command
> the database joins the stored data into the result query.
> This can keep the production database lightweight and fast.
> Regards

DELETE ... RETURNING is useful for this kind of thing, sometimes. And
you could use it inside a function to go and do something with each
row returned, though that might not be very graceful for large numbers
of rows. The proposed syntax wouldn't actually work because it
doesn't specify where to put the data.

...Robert


From: "Omar Bettin" <o(dot)bettin(at)informaticaindustriale(dot)it>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: feature request
Date: 2010-02-25 22:17:03
Message-ID: FAA31728964B4D2F8603021C57ED0A62@fly01
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

...could be
STORE WHERE [condition] FROM [table] INTO [database]

regards
Omar Bettin

----- Original Message -----
From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Omar Bettin" <o(dot)bettin(at)informaticaindustriale(dot)it>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Sent: Thursday, February 25, 2010 11:11 PM
Subject: Re: [HACKERS] feature request

> On Thu, Feb 25, 2010 at 4:35 PM, Omar Bettin
> <o(dot)bettin(at)informaticaindustriale(dot)it> wrote:
>> hello to everyone,
>> is a bit late for an italian, but after an long day debugging I had an
>> idea.
>> Why not introduce a special SQL command like
>> STORE WHERE [condition] FROM [table]
>> removing all data that meet the condition and storing them into another
>> database?
>> Then, if a query that needs the stored data is executed after such
>> command
>> the database joins the stored data into the result query.
>> This can keep the production database lightweight and fast.
>> Regards
>
> DELETE ... RETURNING is useful for this kind of thing, sometimes. And
> you could use it inside a function to go and do something with each
> row returned, though that might not be very graceful for large numbers
> of rows. The proposed syntax wouldn't actually work because it
> doesn't specify where to put the data.
>
> ...Robert
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers


From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Omar Bettin <o(dot)bettin(at)informaticaindustriale(dot)it>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: feature request
Date: 2010-02-25 22:22:31
Message-ID: 603c8f071002251422m60c08146ubb18efe69deae937@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Feb 25, 2010 at 5:17 PM, Omar Bettin
<o(dot)bettin(at)informaticaindustriale(dot)it> wrote:
> ...could be
> STORE WHERE [condition] FROM [table] INTO [database]

That still doesn't work, because a PostgreSQL backend doesn't have any
obvious way to access another database. You'd need to use dblink or
something. Eventually (but not any time soon) it will probably be
possible to do things like this, which would work for moving data
between tables in the same database:

WITH x AS (DELETE FROM ... RETURNING ...) INSERT INTO ... (...) SELECT
... FROM x

Doing anything with some OTHER database is going to require a lot more
infrastructure.

...Robert


From: "Omar Bettin" <o(dot)bettin(at)informaticaindustriale(dot)it>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: feature request
Date: 2010-02-25 22:29:18
Message-ID: BB66E7A182FF4164988A6CB1044FB2AA@fly01
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I have read that 8.5 will have replication, so is just a feature request.

regards
Omar Bettin

----- Original Message -----
From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Omar Bettin" <o(dot)bettin(at)informaticaindustriale(dot)it>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Sent: Thursday, February 25, 2010 11:22 PM
Subject: Re: [HACKERS] feature request

> On Thu, Feb 25, 2010 at 5:17 PM, Omar Bettin
> <o(dot)bettin(at)informaticaindustriale(dot)it> wrote:
>> ...could be
>> STORE WHERE [condition] FROM [table] INTO [database]
>
> That still doesn't work, because a PostgreSQL backend doesn't have any
> obvious way to access another database. You'd need to use dblink or
> something. Eventually (but not any time soon) it will probably be
> possible to do things like this, which would work for moving data
> between tables in the same database:
>
> WITH x AS (DELETE FROM ... RETURNING ...) INSERT INTO ... (...) SELECT
> ... FROM x
>
> Doing anything with some OTHER database is going to require a lot more
> infrastructure.
>
> ...Robert