On 2018-10-17 11:02:40 -0700, Adrian Klaver wrote:
> On 10/17/18 10:57 AM, Ravi Krishna wrote:
> >
> > >
> > > Please note that odbc_fdw is not maintained by the postgresql developers,
> > > but a separate project.
> >
> >
> > Translation: You are on your own. We are hoping this will make our
On 10/17/18 11:12 AM, Ravi Krishna wrote:
Come on. We can't realistically support & debug random postgres extending
projects, nor do we have control over them. And you're not necessarily on your own,
you could report the issue to odbcfdw's authors/github tracker. Or pay a company
for support
Hi,
On 2018-10-17 14:12:01 -0400, Ravi Krishna wrote:
> >
> > Come on. We can't realistically support & debug random postgres extending
> > projects, nor do we have control over them. And you're not necessarily on
> > your own, you could report the issue to odbcfdw's authors/github tracker.
>
>
> Come on. We can't realistically support & debug random postgres extending
> projects, nor do we have control over them. And you're not necessarily on
> your own, you could report the issue to odbcfdw's authors/github tracker. Or
> pay a company for support.
>
On a related note is fdw for
On October 17, 2018 10:57:37 AM PDT, Ravi Krishna wrote:
>
>>
>> Please note that odbc_fdw is not maintained by the postgresql
>developers, but a separate project.
>
>
>Translation: You are on your own. We are hoping this will make our
>migration out of DB2 quicker. Oh well.
Come on. We can'
On 10/17/18 10:57 AM, Ravi Krishna wrote:
Please note that odbc_fdw is not maintained by the postgresql developers, but a
separate project.
Translation: You are on your own. We are hoping this will make our migration
out of DB2 quicker. Oh well.
No it means you need to take this up wi
>
> Please note that odbc_fdw is not maintained by the postgresql developers, but
> a separate project.
Translation: You are on your own. We are hoping this will make our migration
out of DB2 quicker. Oh well.
Hi,
On 2018-10-17 11:17:11 -0400, Ravi Krishna wrote:
> It turned out that enabling ODBC trace was causing PG to crash. Once
> disabled it started working, but found another issue.
> All object names in DB2 is assumed to be upper case. odbc_fdw sends queries
> like this
>
>
> select "fld1","
It turned out that enabling ODBC trace was causing PG to crash. Once disabled
it started working, but found another issue.
All object names in DB2 is assumed to be upper case. odbc_fdw sends queries
like this
select "fld1","fld2" from "schema_name"."table_name".
So the foreign table in PG ha
Don’t agree. Pgsqlms just run pg_ctl with POSIX locale, this is not a bug. But
unreadable messages when locale charset don’t match database charset is bug of
pg_ctl. When messages come from within connection all fine, why don’t do the
same for messages on start/stop?
> 17 окт. 2018 г., в 15:13,
On 10/17/18 2:29 AM, Олег Самойлов wrote:
I think this is a bug, because database encoding logging must work even
in this case. The main problem is with pacemaker module pgsqlms, which
launch pg_ctl in empty environment and thus with broken logging.
I suggest filing an issue here:
https://git
In
https://www.cybertec-postgresql.com/en/ideas-for-scaling-postgresql-to-multi-terabyte-and-beyond/
it is mentioned:
"GIN, the most know non-default index type perhaps, has been actually around
for ages (full-text search) and in short is perfect for indexing columns where
there are lot of re
I think this is a bug, because database encoding logging must work even in this
case. The main problem is with pacemaker module pgsqlms, which launch pg_ctl in
empty environment and thus with broken logging.
Let me explain on examples.
Empty databases:
-bash-4.2$ psql -p 5433 -l
13 matches
Mail list logo
