[
https://issues.jboss.org/browse/TEIID-4251?page=com.atlassian.jira.plugin...
]
Steven Hawkins commented on TEIID-4251:
---------------------------------------
fdw settings are not per pg database? or their fdw settings are
global?
See the sql above. The settings are per server:
CREATE SERVER teiid_server
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host 'TEIID_SERVICE_HOST', port 'TEIID_SERVICE_PORT',
dbname 'VDB'); -- note, this performs no initial validation
CREATE USER MAPPING FOR pg_user
SERVER teiid_server
OPTIONS (user 'TEIID_SECRET_USER', password
'TEIID_SECRET_PASSWORD');
My only concern is the proliferation of a number of pg instances in a
given cluster.
The only thing we could do is have a single pg instance have multiple databases - which is
not something the default install is setup to do.
Maybe we can put in an assumption/limitation over the schema names
and find a way to warn or fail?
Without a patch of the pg fdw there's nothing we can do. The logic expects the local
schema name to be the same at remote.
I agree that we start with the snapshot refresh, when we are ready to
work with CDC we can revisit choices available.
With pg managed materialization there are no additional choices as of yet. It's only
a full refresh - that can be manual, timed, or if we retain a status table based upon some
update threshold.
As per the connectivity from PG to Teiid, can it not be implicitly
trusted over service? if not yes a certificate based auth need to be devised. That may be
useful in general with any other jdbc/odbc client from the within the cluster.
What do you mean by implicitly trusted over service? I'm saying that boils down to
client ip or certificate (either of which would need additional logic).
Built in support for Postgres DB as materialization target
----------------------------------------------------------
Key: TEIID-4251
URL:
https://issues.jboss.org/browse/TEIID-4251
Project: Teiid
Issue Type: Sub-task
Components: Server
Reporter: Ramesh Reddy
Assignee: Steven Hawkins
Priority: Major
Fix For: 12.2
If Postgres database is available along with install or assumed that it is available,
then some of the materialization task can be automated, like
- Creation of a common STATUS table
- Creation of the materilization targets (create views on dbms)
- On load, on undeploy and load scripts for all the materialization views
We need to device a way this to be pluggable, such that based on success of this, we can
provide additional support for other sources.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)