Re: [HACKERS] SAP Application deployment on PostgreSQL
There is still some activities regarding this question like https://blogs.sap.com/2017/05/08/replicate-abap-database-table-definition-to-postgresql/ Maybe PG or EDB (with the Oracle compatibility layer) would have been better strategic choice for SAP to conter ORACLE ;o) -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Continuous integration on Windows?
Oups what a silly boy, I didn't saw that pg10 was released ;o( That's all I need soon (to test Declarative partitioning). Thanks for taking time to answer me in a so detailled and interesting manner. Regards PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Continuous integration on Windows?
This may seems obvious for you but where is the build result ? Is it stored somewhere to permit to users like me that want to test pg 10 on windows without having to build it ? Regards PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Columnar storage support
Thanks a lot for all thoses informations regarding this "Feature" development. I'll try to test VOPS soon, and see if monetdb_fdw support filter and aggregates pushdown ;o) PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Columnar storage support
Is there a chance that pluggable storage permits creation of a columnar rdbms as monetDB in PostgreSQL ? Thanks un advance for thé answer -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Statement-level rollback
There was a mistake in my driver definition, this works fine with autosave=always (but not with autoSave ...) Thanks Again De : Vladimir Sitnikov [via PostgreSQL] <ml-node+s1045698n594805...@n3.nabble.com> Envoyé : mardi 7 mars 2017 22:32:27 À : legrand legrand Objet : Re: Statement-level rollback Please disregard my previous message. pgjdbc is already doing upcase conversion, so I would like to see a test case that reproduces the error. Alternatively, could you please capture and share TRACE log? ( https://jdbc.postgresql.org/documentation/head/logging.html#configuration ) Vladimir ср, 8 мар. 2017 г. в 1:26, Vladimir Sitnikov <[hidden email]>: legrand>when usingversion 42.0.0 with legrand> jdbc:postgresql://localhost:5432/postgres?autosave=always The pitfall there is the value should be written with upper case like autosave=ALWAYS. I've filed https://github.com/pgjdbc/pgjdbc/issues/769 to improve that at some point. Vladimir If you reply to this email, your message will be added to the discussion below: http://www.postgresql-archive.org/Statement-level-rollback-tp5946725p5948059.html To unsubscribe from Statement-level rollback, click here<http://www.postgresql-archive.org/template/NamlServlet.jtp?macro=unsubscribe_by_code=5946725=bGVncmFuZF9sZWdyYW5kQGhvdG1haWwuY29tfDU5NDY3MjV8MjA2NDQ0Mjc1MA==>. NAML<http://www.postgresql-archive.org/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> -- View this message in context: http://www.postgresql-archive.org/Statement-level-rollback-tp5946725p5948076.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
Re: [HACKERS] Statement-level rollback
Thanks ! that's a very good new ! I'm still receiving the famous "current transaction is aborted" error when usingversion 42.0.0 with jdbc:postgresql://localhost:5432/postgres?autosave=always But I will see that with pgjdbc team ;o) Regards PAscal -- View this message in context: http://www.postgresql-archive.org/Statement-level-rollback-tp5946725p5948053.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
Re: [HACKERS] Statement-level rollback
Hello, EDB Oracle compatibility proposes edb_stmt_level_tx parameter, psql uses ON_ERROR_ROLLBACK = 'on', ODBC has a parameter for this JDBC has nothing and developers has to play with savepoint as described http://blog.endpoint.com/2015/02/postgres-onerrorrollback-explained.html This feature (as a GUC at server level) would be very helpfull for Oracle applications migration. Regards PAscal -- View this message in context: http://www.postgresql-archive.org/Statement-level-rollback-tp5946725p5948032.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Partitionning: support for Truncate Table WHERE
here is an exemple :
CREATE OR REPLACE FUNCTION truncate_table_where(v_table VARCHAR,
v_where_condition VARCHAR)
RETURNS void AS $$
DECLARE
v_stmt varchar;
v_tableoid oid;
v_part varchar;
v_found_other integer;
BEGIN
LOOP
v_stmt := 'SELECT tableoid FROM '|| v_table||' WHERE
'||v_where_condition||' limit 1 ';
EXECUTE v_stmt INTO v_tableoid;
IF (v_tableoid is null) THEN
EXIT;
END IF;
Select pg_namespace.nspname||'.'||pg_class.relname into v_part from
pg_catalog.pg_class
INNER JOIN pg_namespace
ON pg_class.relnamespace = pg_namespace.oid where pg_class.oid =
v_tableoid;
RAISE NOTICE 'Partition found: %', v_part;
-- check if other data in part
v_stmt := 'SELECT 1 FROM '|| v_part||' WHERE NOT ('||v_where_condition||')
limit 1 ';
EXECUTE v_stmt INTO v_found_other;
IF (v_found_other =1) THEN
v_stmt := 'DELETE FROM '|| v_part||' WHERE '||v_where_condition;
RAISE NOTICE 'Executing: %', v_stmt;
EXECUTE v_stmt;
ELSE
v_stmt := 'TRUNCATE '|| v_part;
RAISE NOTICE 'Executing: %', v_stmt;
EXECUTE v_stmt;
END IF;
END LOOP;
END
$$ LANGUAGE plpgsql;
;
De : Amit Langote <langote_amit...@lab.ntt.co.jp>
Envoyé : mercredi 7 décembre 2016 06:58:03
À : Craig Ringer; legrand legrand
Cc : pgsql-hackers@postgresql.org
Objet : Re: [HACKERS] Partitionning: support for Truncate Table WHERE
On 2016/12/07 15:26, Craig Ringer wrote:
> On 7 December 2016 at 07:29, legrand legrand
> <legrand_legr...@hotmail.com> wrote:
>
>> Working in a DSS environment, we often need to truncate table partitions
>> regarding a WHERE condition and have to
>> [...]
>> Would be pleased to ear your feedback regarding this.
>
> It sounds like something that'd be useful to do on top of declarative
> partitioning, once that is merged. Perhaps you could start by reading
> and testing the declarative partitioning patch. That'll give you a
> better idea of the practicalities of doing what you propose on top of
> it, and give you an opportunity to suggest changes to the declarative
> partitioning scheme that might make conditional truncate easier later.
Agreed.
If I understand the request correctly, TRUNCATE on the parent table (a
partitioned table), which currently recurses to *all* child tables
(partitions), should have a restricting WHERE clause, right? It would
become possible to implement something like that with the new declarative
partitioned tables. As Crag mentioned, you can take a look at the
discussion about declarative partitioning in the emails linked to at the
following page: https://commitfest.postgresql.org/12/611/
Thanks,
Amit
[HACKERS] Partitionning: support for Truncate Table WHERE
Hello, Working in a DSS environment, we often need to truncate table partitions regarding a WHERE condition and have to: - query the dictionnary to identify thoses partitions, - build SQL statements, - truncate all partitions covered by the WHERE condition - eventually delete the rest ... - perform additionnal maintenance tasks Wouldn't it be possible to make it possible directly in SQL as a TRUNCATE TABLE WHERE syntax ? I have done something similar using a procedure in Oracle: - identifying partitions using oracle rowids by a SELECT using the same WHERE conditions - for each partition check if data NOT in WHERE condition - then DELETE WHERE or TRUNCATE PARTITION depending of data distribution. Maybe there are some other constrainst like locking, FK disabling/enabling, indexes rebuild ... Would be pleased to ear your feedback regarding this. Regards PAscal
