On Wed, 11 Jan 2017 15:23:10 -0800, John R Pierce
wrote:
>On 1/11/2017 2:07 PM, Ian Lewis wrote:
>> I am working on porting from an SQL Anywhere server that has support
>> for general temporary tables. It appears that PostgreSQL does not have
>> such support.
>
>postgres temporary tables are ei
On Wed, Jan 11, 2017 at 05:54:11PM -0700, David G. Johnston wrote:
> I don't see where "call a setup function immediately after connecting"
Sounds like a "login trigger", more generally an ON CONNECT
event trigger, which we don't have at the moment as far as I
know.
One of the main arguments aga
Hi
2017-01-12 10:06 GMT+01:00 Karsten Hilbert :
> On Wed, Jan 11, 2017 at 05:54:11PM -0700, David G. Johnston wrote:
>
> > I don't see where "call a setup function immediately after connecting"
>
> Sounds like a "login trigger", more generally an ON CONNECT
> event trigger, which we don't have at
Karsten Hilbert wrote:
On Wed, Jan 11, 2017 at 05:54:11PM -0700, David G. Johnston wrote:
I don't see where "call a setup function immediately after connecting"
Sounds like a "login trigger", more generally an ON CONNECT
event trigger, which we don't have at the moment as far as I
know.
One
Hi PostgresPro-guys.
I've asked this before but didn't get any response, so I'll try again. I know
you have a lot on you plate...
On RUM's TODO-list is this:
* Allow multiple additional information (lexemes positions + timestamp).
* Add support for arrays. Will any of these items support
On 01/12/2017 12:37 AM, George Neuner wrote:
On Wed, 11 Jan 2017 15:23:10 -0800, John R Pierce
wrote:
On 1/11/2017 2:07 PM, Ian Lewis wrote:
I am working on porting from an SQL Anywhere server that has support
for general temporary tables. It appears that PostgreSQL does not have
such support
On Jan 11, 2017, at 8:19 PM, Melvin Davidson wrote:
>
> Yes, you're right about ALTER SYSTER. Unfortunately, the op provided neither
> PostgreSQL version or O/S, so we can't even be sure that is
> an option. That is why I stated "I cannot confirm".
I didn't think that would matter, but postg
On Wed, Jan 11, 2017 at 5:36 PM, Adrian Klaver
wrote:
>
> So what is the relationship of clients to sessions?
Most of our client applications use one session. But, a few use multiple
sessions, largely to support threaded access to the database. In our
current setup, a session connection may only
I'm just wondering if there's a more efficient way of handling a certain
periodic data migration.
We have a pair of tables with this structure:
table_a__live
column_1 INT
column_2 INT
record_timestamp TIMESTAMP
table_a__archive
- Original Message -
> From: "Jonathan Vanasco"
> To: "pgsql-general general"
> Sent: Thursday, January 12, 2017 3:06:14 PM
> Subject: [GENERAL] efficiently migrating 'old' data from one table to another
>
> I'm just wondering if there's a more efficient way of handling a certain
> per
On 1/12/2017 12:06 PM, Jonathan Vanasco wrote:
I'm just wondering if there's a more efficient way of handling a certain
periodic data migration.
partition the tables by some date interval such as week (if you do this
archiving weekly). each week, disconnect the oldest partition from the
'a
On 01/12/2017 12:06 PM, Jonathan Vanasco wrote:
> I'm just wondering if there's a more efficient way of handling a certain
> periodic data migration.
>
> We have a pair of tables with this structure:
>
> table_a__live
> column_1 INT
> column_2 INT
>
On Thu, Jan 12, 2017 at 2:45 PM, Adrian Klaver
wrote:
>
> > so our migration is then based on that `is_migrate` column:
> >
> > BEGIN;
> > UPDATE table_a__live SET is_migrate = TRUE WHERE record_timestamp
> < transaction_timestamp() AT TIME ZONE 'UTC' - INTERVAL '1 month';
> > I
On Thu, Jan 12, 2017 at 2:19 PM, bto...@computer.org
wrote:
>
>
> - Original Message -
>> From: "Jonathan Vanasco"
>> To: "pgsql-general general"
>> Sent: Thursday, January 12, 2017 3:06:14 PM
>> Subject: [GENERAL] efficiently migrating 'old' data from one table to another
>>
>> I'm just
14 matches
Mail list logo
