"Statistics" tab is very slow

[Petr Fedorov]

Hello,

I'm using pgAdmin 4 version 3.6 on Centos 7, Postgresql 10.6 runs on the
same machine. I use local connections.

Almost everything works fine except for 'Statistics' tab when viewing
pgAgent job log. It takes 60-90 seconds to load, the whole pgAdmin4 is
frozen during the load, Firefox shows yellow bar suggesting to stop
slowly running tab.  Deleting job log entries (leaving few dozens) has
little impact.

Can it be fixed somehow?

P.S. Sometimes opening Query Tool is also slow (15-20 seconds to
connect) or is not able to connect at all. But closing it and opening
again  always works fine.

Re: "Statistics" tab is very slow

[Khushboo Vashi]

Hi,

On Tue, Jan 8, 2019 at 3:59 PM Petr Fedorov 
wrote:

> Hello,
>
> I'm using pgAdmin 4 version 3.6 on Centos 7, Postgresql 10.6 runs on the
> same machine. I use local connections.
>
> Almost everything works fine except for 'Statistics' tab when viewing
> pgAgent job log. It takes 60-90 seconds to load, the whole pgAdmin4 is
> frozen during the load, Firefox shows yellow bar suggesting to stop
> slowly running tab.  Deleting job log entries (leaving few dozens) has
> little impact.
>
> This has already been reported. Please check the RM #3664
https://redmine.postgresql.org/issues/3664

> Can it be fixed somehow?
>
> P.S. Sometimes opening Query Tool is also slow (15-20 seconds to
> connect) or is not able to connect at all. But closing it and opening
> again  always works fine.

This has already been fixed. https://redmine.postgresql.org/issues/3679
You will get this fix in the next release which is very soon.

>
>

Re: Import/Export failure due to UTF-8 error in pgAdmin4 but not in pgAdmin3

[richard coleman]

Dave,

Thanks for continuing this discussion, but I think you misunderstand the
situation.  I am storing *valid* *non-UTF8* data in a SQL_ASCII encoded
postgreSQL database (please re-read what I had previously written). This is
why psql has *NO* problem dealing with it.  This is also why Windows ODBC
and .Net applications have *NO* problem dealing with it.  In fact the most
common character that pgAdmin4 crashes on is the Windows *smart quote*.  So
to reiterate, I am using *valid **non-UTF8* characters in a SQL_ASCII
database.  This is a supported configuration for postgreSQL.  The issue
seems to be that pgAdmin4 is *assuming * UTF8 data and
crashing/failing/throwing errors when it encounters invalid UTF8 characters.

I hope I have made the situation a little bit clearer.

Thanks again,

rik.

On Tue, Jan 8, 2019 at 12:29 AM Dave Page  wrote:

> Hi
>
> On Tue, Jan 8, 2019 at 12:47 AM richard coleman
>  wrote:
> >
> > Dave,
> >
> > Thanks for taking the time to respond, but I don't see anywhere that
> SQL_ASCII is recommended against doing. Here's the documentation listing
> the supported encoding schemas:
> https://www.postgresql.org/docs/current/multibyte.html .
> >
> > The only caveats listed for SQL_ASCII are:
> >>
> >> In most cases, if you are working with any non-ASCII data, it is unwise
> to use the SQL_ASCII setting because PostgreSQL will be unable to help you
> by converting or validating non-ASCII characters.
>
> You highlighted it below: "If the client character set is defined as
> SQL_ASCII, encoding conversion is disabled, regardless of the server's
> character set. Just as for the server, use of SQL_ASCII is unwise
> unless you are working with all-ASCII data"
>
> You're using UTF-8 data, not ASCII, which it says is unwise because
> conversion won't take place (and consequently, neither will
> validation). I don't see how one could read that and not take it as
>
> You are running into exactly that problem; and it's visible when
> working with technologies that are strict about following encoding
> rules - in this case, psql when pgAdmin shells out to it.
>
> I did think of one possible quick fix this morning which I'll look
> into, but as I noted before; it's a workaround, and the real problem
> is storing un-validated UTF-8 data in a SQL_ASCII database.
>
> > Or, a reminder that postgreSQL can't help with any conversions you might
> want to do.
> >
> > Then there's this:
> >>
> >> PostgreSQL will allow superusers to create databases with SQL_ASCII
> encoding even when LC_CTYPE is not C or POSIX. As noted above, SQL_ASCII
> does not enforce that the data stored in the database has any particular
> encoding, and so this choice poses risks of locale-dependent misbehavior.
> Using this combination of settings is deprecated and may someday be
> forbidden altogether.
> >
> >
> > A note that you can currently choose incompatible settings, but probably
> can't in the future.
> >
> > And finally there's this bit of advice:
> >>
> >> If the client character set is defined as SQL_ASCII, encoding
> conversion is disabled, regardless of the server's character set. Just as
> for the server, use of SQL_ASCII is unwise unless you are working with
> all-ASCII data[emphasis mine].
> >
> >
> > Which is just a reiteration of the first caveat, that if you are using
> SQL_ASCII the database won't perform any conversions on your behalf.
> >
> > That is hardly a recommendation against using that supported encoding
> scheme.  The fact that the psql command prompt, among others, works with it
> without issue, is an indication that the problem lies in pgAdmin4 (and I
> would guess the reliance of python on UTF8) than an issue with the database
> itself.  pgAdmin4 needs to check for and more gracefully handle valid
> postgreSQL data that might happen to be not UTF8 compliant.
> >
> > Until then, I will have to periodically scan and clean for bad UTF8 data
> to keep pgAdmin4 (and other JDBC dependent code) happy.  The legacy
> enterprise .Net applications that depend on it prohibit converting it to
> UTF8 (or anything else for that matter).
> >
> > Just my $0.02,
> >
> > rik.
> >
> >
> > On Mon, Jan 7, 2019 at 1:27 PM Dave Page  wrote:
> >>
> >> Hi
> >>
> >> On Mon, Jan 7, 2019 at 11:30 PM richard coleman
> >>  wrote:
> >> >
> >> > Dave,
> >> >
> >> > I can't speak to Nania's specific issue, but I believe it's a
> pgAdmin4 specific problem, at least in so far as SQL_ASCII is concerned.  I
> say this because I can usually work with the data just fine from the psql
> prompt, but not through pgAdmin4 (or other postgreSQL GUI's like dBeaver
> that rely on the JDBC connection).  .Net/Windows ODBC drivers and psql
> command prompt, no problem (as was pgAdmin3 assuming you don't do too much
> with it beyond select/update/insert).  pgAdmin4, SELECT, export, etc. BOOM!
> At least until you cleaned  up the offending bytes.
> >> >
> >> > Just my $0.02.
> >>
> >> I'm afraid the fundamental problem is that you're using PostgreSQL i

Re: Import/Export failure due to UTF-8 error in pgAdmin4 but not in pgAdmin3

[Dave Page]

Hi Rik

On Tue, Jan 8, 2019 at 6:53 PM richard coleman
 wrote:
>
> Dave,
>
> Thanks for continuing this discussion, but I think you misunderstand the 
> situation.  I am storing valid non-UTF8 data in a SQL_ASCII encoded 
> postgreSQL database (please re-read what I had previously written). This is 
> why psql has NO problem dealing with it.  This is also why Windows ODBC and 
> .Net applications have NO problem dealing with it.  In fact the most common 
> character that pgAdmin4 crashes on is the Windows smart quote.  So to 
> reiterate, I am using valid non-UTF8 characters in a SQL_ASCII database.  
> This is a supported configuration for postgreSQL.  The issue seems to be that 
> pgAdmin4 is assuming  UTF8 data and crashing/failing/throwing errors when it 
> encounters invalid UTF8 characters.
>
> I hope I have made the situation a little bit clearer.

Well psql is failing to deal with it *in this case*, as that's what is
doing the \copy in the import/export tool.

In other cases (i.e. the ones where pgAdmin sees the data, such as
results in the query tool), the issue arises because Python and/or
Javascript (and by extension pgAdmin) may barf on data encoded in a
way they don't recognise. That's why the PostgreSQL docs say to only
use ASCII data in SQL_ASCII databases - the behaviour is undefined,
and as a result may either not render properly or may crash or error
on non-ASCII data.

Anyhoo, I expect to have a little time after dinner shortly so I'll
try out the workaround I thought of earlier to see if it helps (I
doubt it'll be a panacea, but it may help in some cases).

By any chance do you have a test case you can share with me that
refuses to export from pgAdmin (using the Import/Export tool)? If so,
I'd appreciate a copy of it to play with.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Import/Export failure due to UTF-8 error in pgAdmin4 but not in pgAdmin3

[richard coleman]

Dave,

I would imagine Nanina would be in a better position to provide you with
problematic import/export data in the short term.  I don't tend to
import/export that often these days, preferring to use SQL statements for
most things short of a full backup/restore (in my case I've found it to be
much less *picky).* As mentioned previously, in my experience the
characters that tend to trip up pgAdmin4 are Windows *special characters.  *I
would imagine the upper Windows-1252 character set as being particularly
problematic for pgAdmin4 if it is expecting *proper UTF-8* (i.e.
ŒœŠšŸŽžƒˆ˜–—‘’‚“”„†‡•…‰‹›€™).  This would explain why Windows ODBC, .Net,
and pSQL have no problems dealing with the data.  I would imagine *if* it
the database was set up with  ENCODING =  'WIN1252' then postgreSQL would
do the translation into UTF-8 for pgAdmin4, but since it isn't postgreSQL
can't provide pgAdmin4 with any help.  It's up to pgAdmin4 to deal with the
otherwise valid data appropriately.

I hope your *workaround* pans out, until then I will spend my time at the
psql prompt, or if the data is needed elsewhere run the two functions I had
included previously to identify and remove the offensive characters.

Here's the create database script for one of my databases, perhaps it can
shed some light (it was originally an 8.3 postgreSQL database {long before
my time here, currently running under postgreSQL 10.x} and apparently back
then it defaulted to creating SQL_ASCII encoded databases on Windows).

CREATE DATABASE tms_production
> WITH
> OWNER = local_user
> ENCODING = 'SQL_ASCII'
> LC_COLLATE = 'English_United States.1252'
> LC_CTYPE = 'English_United States.1252'
> TABLESPACE = pg_default
> CONNECTION LIMIT = -1;
> ALTER DATABASE tms_production
> SET default_transaction_read_only TO off;
> ALTER DATABASE tms_production
> SET client_encoding TO sql_ascii;
> ALTER DATABASE tms_production
> SET standard_conforming_strings TO off;


rik.

On Tue, Jan 8, 2019 at 8:37 AM Dave Page  wrote:

> Hi Rik
>
> On Tue, Jan 8, 2019 at 6:53 PM richard coleman
>  wrote:
> >
> > Dave,
> >
> > Thanks for continuing this discussion, but I think you misunderstand the
> situation.  I am storing valid non-UTF8 data in a SQL_ASCII encoded
> postgreSQL database (please re-read what I had previously written). This is
> why psql has NO problem dealing with it.  This is also why Windows ODBC and
> .Net applications have NO problem dealing with it.  In fact the most common
> character that pgAdmin4 crashes on is the Windows smart quote.  So to
> reiterate, I am using valid non-UTF8 characters in a SQL_ASCII database.
> This is a supported configuration for postgreSQL.  The issue seems to be
> that pgAdmin4 is assuming  UTF8 data and crashing/failing/throwing errors
> when it encounters invalid UTF8 characters.
> >
> > I hope I have made the situation a little bit clearer.
>
> Well psql is failing to deal with it *in this case*, as that's what is
> doing the \copy in the import/export tool.
>
> In other cases (i.e. the ones where pgAdmin sees the data, such as
> results in the query tool), the issue arises because Python and/or
> Javascript (and by extension pgAdmin) may barf on data encoded in a
> way they don't recognise. That's why the PostgreSQL docs say to only
> use ASCII data in SQL_ASCII databases - the behaviour is undefined,
> and as a result may either not render properly or may crash or error
> on non-ASCII data.
>
> Anyhoo, I expect to have a little time after dinner shortly so I'll
> try out the workaround I thought of earlier to see if it helps (I
> doubt it'll be a panacea, but it may help in some cases).
>
> By any chance do you have a test case you can share with me that
> refuses to export from pgAdmin (using the Import/Export tool)? If so,
> I'd appreciate a copy of it to play with.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: Import/Export failure due to UTF-8 error in pgAdmin4 but not in pgAdmin3

[richard coleman]

Nanina,

I am glad to hear that you are finding the discussion illuminating. You
might want to send a copy of your backup file (assuming it isn't sensitive
data) to Dave so that he can test pgAdmin4 against it.  You might also want
to provide your OS and postgreSQL information as well.  I've noticed that
your collation is DE (German) perhaps the issue is accented characters?
You can run the *is_UTF8()* function I've provided, it is non destructive
and just returns a Boolean that indicates whether or not there are any
characters in the selected column that aren't valid UTF8.  For example in
the table *table1 *to check the text field *notes* for invalid characters
you could run:

SELECT id, is_UTF8(notes) from table1 WHERE is_UTF8(notes) = false;


This would return the list of id's of records that had invalid UTF8
characters in the notes field. You should be able to use that to narrow
down the issue.

I hope that helps,

rik.

On Tue, Jan 8, 2019 at 9:21 AM Nanina Tron  wrote:

> Hi,
>
> thanks for the multiple responses and interesting discussion I am
> struggeling to keep up with all the new information.
> I double checked, all settings I could find and the .csv files I want to
> import. Everything is manually, or at creation of the db set to UTF8. I
> tried to copy one of the tables via backup/restore what worked, but of
> course I migrated the problem with it.
> I just don't see where I did something wrong. As you referred to the
> documentation https://www.postgresql.org/docs/current/multibyte.html,
> this was the information why I created the db in UTF8 in the first place.
> This is the SQL code of the db (from pgAdmin4 tab)
>CREATE DATABASE testdb
> WITH
> OWNER = postgres
> ENCODING = 'UTF8'
> LC_COLLATE = 'de_DE.UTF-8'
> LC_CTYPE = 'de_DE.UTF-8'
> TABLESPACE = pg_default
> CONNECTION LIMIT = -1;
>
> So what I understand from your explanations is that I imported kind of
> invalid data with pgAdmin3 to begin with and now can't copy these tables in
> pgAdmin4 because psql has a problem with it? If so why can't I import a new
> .csv file in UTF8 into an new created table with pgAdmin4? I just have one
> option to generate the .csv in UTF8 with Excel and this isn't working.
>
> I did not try to eliminate the problematic characters with your code ric,
> as I am not sure if there are characters we really need, so I would prefere
> not to alter the data.
>
> I am not sure if that helps, but I just append the file I am not able to
> Import.
>
> Thanks a lot so far,
> Nanina
>
> _
>
>
> Am 08. Januar 2019 um 15:02 schrieb richard coleman <
> rcoleman.ascen...@gmail.com>:
>
> Dave,
>
> I would imagine Nanina would be in a better position to provide you with
> problematic import/export data in the short term.  I don't tend to
> import/export that often these days, preferring to use SQL statements for
> most things short of a full backup/restore (in my case I've found it to be
> much less *picky).* As mentioned previously, in my experience the
> characters that tend to trip up pgAdmin4 are Windows *special
> characters.  *I would imagine the upper Windows-1252 character set as
> being particularly problematic for pgAdmin4 if it is expecting *proper
> UTF-8* (i.e. ŒœŠšŸŽžƒˆ˜–—‘’‚“”„†‡•…‰‹›€™).  This would explain why
> Windows ODBC, .Net, and pSQL have no problems dealing with the data.  I
> would imagine *if* it the database was set up with  ENCODING =  'WIN1252'
> then postgreSQL would do the translation into UTF-8 for pgAdmin4, but since
> it isn't postgreSQL can't provide pgAdmin4 with any help.  It's up to
> pgAdmin4 to deal with the otherwise valid data appropriately.
>
> I hope your *workaround* pans out, until then I will spend my time at the
> psql prompt, or if the data is needed elsewhere run the two functions I had
> included previously to identify and remove the offensive characters.
>
> Here's the create database script for one of my databases, perhaps it can
> shed some light (it was originally an 8.3 postgreSQL database {long before
> my time here, currently running under postgreSQL 10.x} and apparently back
> then it defaulted to creating SQL_ASCII encoded databases on Windows).
>
> CREATE DATABASE tms_production
>> WITH
>> OWNER = local_user
>> ENCODING = 'SQL_ASCII'
>> LC_COLLATE = 'English_United States.1252'
>> LC_CTYPE = 'English_United States.1252'
>> TABLESPACE = pg_default
>> CONNECTION LIMIT = -1;
>> ALTER DATABASE tms_production
>> SET default_transaction_read_only TO off;
>> ALTER DATABASE tms_production
>> SET client_encoding TO sql_ascii;
>> ALTER DATABASE tms_production
>> SET standard_conforming_strings TO off;
>
>
> rik.
>
> On Tue, Jan 8, 2019 at 8:37 AM Dave Page  wrote:
>
>> Hi Rik
>>
>> On Tue, Jan 8, 2019 at 6:53 PM richard coleman
>>  wrote:
>> >
>> > Dave,
>> >
>> > Thanks for continuing this discussion, but I think you misunderstand
>> the situation.  I 

Re: Import/Export failure due to UTF-8 error in pgAdmin4 but not in pgAdmin3

[Nanina Tron]

Hi,



thanks for the multiple responses and interesting discussion I am struggeling 
to keep up with all the new information.

I double checked, all settings I could find and the .csv files I want to 
import. Everything is manually, or at creation of the db set to UTF8. I tried 
to copy one of the tables via backup/restore what worked, but of course I 
migrated the problem with it.
I just don't see where I did something wrong. As you referred to the 
documentation https://www.postgresql.org/docs/current/multibyte.html, this was 
the information why I created the db in UTF8 in the first place.
This is the SQL code of the db (from pgAdmin4 tab)

   CREATE DATABASE testdb
    WITH
    OWNER = postgres
    ENCODING = 'UTF8'
    LC_COLLATE = 'de_DE.UTF-8'
    LC_CTYPE = 'de_DE.UTF-8'
    TABLESPACE = pg_default
    CONNECTION LIMIT = -1;


So what I understand from your explanations is that I imported kind of invalid 
data with pgAdmin3 to begin with and now can't copy these tables in pgAdmin4 
because psql has a problem with it? If so why can't I import a new .csv file in 
UTF8 into an new created table with pgAdmin4? I just have one option to 
generate the .csv in UTF8 with Excel and this isn't working.



I did not try to eliminate the problematic characters with your code ric, as I 
am not sure if there are characters we really need, so I would prefere not to 
alter the data.



I am not sure if that helps, but I just append the file I am not able to Import.



Thanks a lot so far,

Nanina



_



Am 08. Januar 2019 um 15:02 schrieb richard coleman 
:


Dave, 


I would imagine Nanina would be in a better position to provide you with 
problematic import/export data in the short term.  I don't tend to 
import/export that often these days, preferring to use SQL statements for most 
things short of a full backup/restore (in my case I've found it to be much less 
picky). As mentioned previously, in my experience the characters that tend to 
trip up pgAdmin4 are Windows special characters.  I would imagine the upper 
Windows-1252 character set as being particularly problematic for pgAdmin4 if it 
is expecting proper UTF-8 (i.e. ŒœŠšŸŽžƒˆ˜–—‘’‚“”„†‡•…‰‹›€™).  This would 
explain why Windows ODBC, .Net, and pSQL have no problems dealing with the 
data.  I would imagine if it the database was set up with  ENCODING =  
'WIN1252' then postgreSQL would do the translation into UTF-8 for pgAdmin4, but 
since it isn't postgreSQL can't provide pgAdmin4 with any help.  It's up to 
pgAdmin4 to deal with the otherwise valid data appropriately.


I hope your workaround pans out, until then I will spend my time at the psql 
prompt, or if the data is needed elsewhere run the two functions I had included 
previously to identify and remove the offensive characters.


Here's the create database script for one of my databases, perhaps it can shed 
some light (it was originally an 8.3 postgreSQL database {long before my time 
here, currently running under postgreSQL 10.x} and apparently back then it 
defaulted to creating SQL_ASCII encoded databases on Windows).


CREATE DATABASE tms_production
    WITH 
    OWNER = local_user
    ENCODING = 'SQL_ASCII'
    LC_COLLATE = 'English_United States.1252'
    LC_CTYPE = 'English_United States.1252'
    TABLESPACE = pg_default
    CONNECTION LIMIT = -1;
ALTER DATABASE tms_production
    SET default_transaction_read_only TO off;
ALTER DATABASE tms_production
    SET client_encoding TO sql_ascii;
ALTER DATABASE tms_production
    SET standard_conforming_strings TO off;  


rik. 


On Tue, Jan 8, 2019 at 8:37 AM Dave Page  wrote:

Hi Rik

On Tue, Jan 8, 2019 at 6:53 PM richard coleman
 wrote:


Dave,

Thanks for continuing this discussion, but I think you misunderstand the 
situation.  I am storing valid non-UTF8 data in a SQL_ASCII encoded postgreSQL 
database (please re-read what I had previously written). This is why psql has 
NO problem dealing with it.  This is also why Windows ODBC and .Net 
applications have NO problem dealing with it.  In fact the most common 
character that pgAdmin4 crashes on is the Windows smart quote.  So to 
reiterate, I am using valid non-UTF8 characters in a SQL_ASCII database.  This 
is a supported configuration for postgreSQL.  The issue seems to be that 
pgAdmin4 is assuming  UTF8 data and crashing/failing/throwing errors when it 
encounters invalid UTF8 characters.

I hope I have made the situation a little bit clearer.


Well psql is failing to deal with it *in this case*, as that's what is
doing the \copy in the import/export tool.

In other cases (i.e. the ones where pgAdmin sees the data, such as
results in the query tool), the issue arises because Python and/or
Javascript (and by extension pgAdmin) may barf on data encoded in a
way they don't recognise. That's why the PostgreSQL docs say to only
use ASCII data in SQL_ASCII databases - the behaviour is undefined,
and as a result may either not render prop

Change browser in MacOS

[Steve Hawes]

Hi,

Can anyone help me with changing the browser used by pgAdmin in MacOS Mojave.

I have Google Chrome installed and can see that there is a box for entering the 
Browser Command in the pgAdmin configuration but I cannot work out the syntax 
for getting Chrome to launch instead of Safari. Any help appreciated.

Many thanks
Steve

Steve Hawes
CIO
T: 020 3355 9796
M: +34 681 259 532
E: steve.ha...@tmlep.com
W: www.tmlep.com
TMLEP | The Medico-Legal Experts Practice
Consider the environment. Do you really need to print this email?
TMLE Limited is a company registered in England and Wales under number 
08092743. The company's registered office is The Chestnuts, Brewers End, 
Takeley, Essex CM22 6QJ United Kingdom.

This message contains confidential information and is intended only for the 
intended recipients. If you are not an intended recipient you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. E-mail transmission cannot be guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses. The sender therefore 
does not accept liability for any errors or omissions in the contents of this 
message, which arise as a result of e-mail transmission. If verification is 
required please request a hard-copy version.

TMLEP may monitor email traffic data and also the content of emails for 
compliance purposes and to protect its business.

Re: Change browser in MacOS

[richard coleman]

Steve,

Well I have mine set to launch chromium with this command:

> chromium-browser %URL%


So I would imagine substituting the command to start chrome from the
command line would suffice.

Just a thought,

rik.

On Tue, Jan 8, 2019 at 10:02 AM Steve Hawes  wrote:

> Hi,
>
>
>
> Can anyone help me with changing the browser used by pgAdmin in MacOS
> Mojave.
>
>
>
> I have Google Chrome installed and can see that there is a box for
> entering the Browser Command in the pgAdmin configuration but I cannot work
> out the syntax for getting Chrome to launch instead of Safari. Any help
> appreciated.
>
>
>
> Many thanks
>
> Steve
>
> Steve Hawes​
> CIO
>
> T:  *020 3355 9796* <020%203355%209796>
> M:  *+34 681 259 532* <+34%20681%20259%20532>
> E:  *steve.ha...@tmlep.com* 
> W:  *www.tmlep.com*  [image: TMLEP | The
> Medico-Legal Experts Practice] 
> Consider the environment. Do you really need to print this email?
> TMLE Limited is a company registered in England and Wales under number
> 08092743. The company's registered office is The Chestnuts, Brewers
> End, Takeley, Essex CM22 6QJ United Kingdom.
>
> This message contains confidential information and is intended only for
> the intended recipients. If you are not an intended recipient you should
> not disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system. E-mail transmission cannot be
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
> The sender therefore does not accept liability for any errors or omissions
> in the contents of this message, which arise as a result of e-mail
> transmission. If verification is required please request a hard-copy
> version.
>
> TMLEP may monitor email traffic data and also the content of emails for
> compliance purposes and to protect its business.
>
>

Re: Change browser in MacOS

[Strauch, Sheldon]

Interestingly enough, I use Chrome exclusively and my Browser Command is
configured to: */usr/bin/firefox %URL%*
When selecting *New pgAdmin 4 Window...* the new window opens in Chrome.
Seeing as firefox is not even installed, I believe in the absence of a
working command pgAdmin 4 reverts to OSX's default browser, which I do have
configured to be chrome.

HTH!

On Tue, Jan 8, 2019 at 9:33 AM richard coleman 
wrote:

> Steve,
>
> Well I have mine set to launch chromium with this command:
>
>> chromium-browser %URL%
>
>
> So I would imagine substituting the command to start chrome from the
> command line would suffice.
>
> Just a thought,
>
> rik.
>
> On Tue, Jan 8, 2019 at 10:02 AM Steve Hawes  wrote:
>
>> Hi,
>>
>>
>>
>> Can anyone help me with changing the browser used by pgAdmin in MacOS
>> Mojave.
>>
>>
>>
>> I have Google Chrome installed and can see that there is a box for
>> entering the Browser Command in the pgAdmin configuration but I cannot work
>> out the syntax for getting Chrome to launch instead of Safari. Any help
>> appreciated.
>>
>>
>>
>> Many thanks
>>
>> Steve
>>
>> Steve Hawes​
>> CIO
>>
>> T:  *020 3355 9796* <020%203355%209796>
>> M:  *+34 681 259 532* <+34%20681%20259%20532>
>> E:  *steve.ha...@tmlep.com* 
>> W:  *www.tmlep.com*
>> 
>>  [image:
>> TMLEP | The Medico-Legal Experts Practice]
>> 
>> Consider the environment. Do you really need to print this email?
>> TMLE Limited is a company registered in England and Wales under number
>> 08092743. The company's registered office is The Chestnuts, Brewers
>> End, Takeley, Essex CM22 6QJ United Kingdom.
>>
>> This message contains confidential information and is intended only for
>> the intended recipients. If you are not an intended recipient you should
>> not disseminate, distribute or copy this e-mail. Please notify the sender
>> immediately by e-mail if you have received this e-mail by mistake and
>> delete this e-mail from your system. E-mail transmission cannot be
>> guaranteed to be secure or error-free as information could be intercepted,
>> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
>> The sender therefore does not accept liability for any errors or omissions
>> in the contents of this message, which arise as a result of e-mail
>> transmission. If verification is required please request a hard-copy
>> version.
>>
>> TMLEP may monitor email traffic data and also the content of emails for
>> compliance purposes and to protect its business.
>>
>>

-- 

Look after your data, and your database will look after you. -- Simon Riggs

Sheldon E. Strauch
*Data Architect, Data Services *
*O* 312-676-1556
*M* 224-723-3878

*Enova International, Inc.*
*This transmission is confidential and may be privileged or proprietary. If
you are not the intended recipient, you are not authorized to use the
information in this transmission in any way. Please inform the sender
immediately if you have received this transmission in error and permanently
delete and destroy the original and any copies of the information.*

Re: Change browser in MacOS

[Dave Page]

Hi

On Tue, Jan 8, 2019 at 8:32 PM Steve Hawes  wrote:

> Hi,
>
>
>
> Can anyone help me with changing the browser used by pgAdmin in MacOS
> Mojave.
>
>
>
> I have Google Chrome installed and can see that there is a box for
> entering the Browser Command in the pgAdmin configuration but I cannot work
> out the syntax for getting Chrome to launch instead of Safari. Any help
> appreciated.
>
>
>
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" %URL%

Should do the trick. You need the quotes because of the spaces in the path.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Change browser in MacOS

[Dave Page]

Hi

On Tue, Jan 8, 2019 at 9:12 PM Strauch, Sheldon  wrote:

> Interestingly enough, I use Chrome exclusively and my Browser Command is
> configured to: */usr/bin/firefox %URL%*
>

I think you'll find that's the placeholder hint text, not a value. I'll bet
you can't copy/paste it, and if you try to edit the field, it'll only let
you add a new value, not edit what you see. Most OS's will display that in
a lighter colour than normal text.


> When selecting *New pgAdmin 4 Window...* the new window opens in Chrome.
> Seeing as firefox is not even installed, I believe in the absence of a
> working command pgAdmin 4 reverts to OSX's default browser, which I do have
> configured to be chrome.
>
> HTH!
>
> On Tue, Jan 8, 2019 at 9:33 AM richard coleman <
> rcoleman.ascen...@gmail.com> wrote:
>
>> Steve,
>>
>> Well I have mine set to launch chromium with this command:
>>
>>> chromium-browser %URL%
>>
>>
>> So I would imagine substituting the command to start chrome from the
>> command line would suffice.
>>
>> Just a thought,
>>
>> rik.
>>
>> On Tue, Jan 8, 2019 at 10:02 AM Steve Hawes 
>> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> Can anyone help me with changing the browser used by pgAdmin in MacOS
>>> Mojave.
>>>
>>>
>>>
>>> I have Google Chrome installed and can see that there is a box for
>>> entering the Browser Command in the pgAdmin configuration but I cannot work
>>> out the syntax for getting Chrome to launch instead of Safari. Any help
>>> appreciated.
>>>
>>>
>>>
>>> Many thanks
>>>
>>> Steve
>>>
>>> Steve Hawes
>>> CIO
>>>
>>> T:  *020 3355 9796* <020%203355%209796>
>>> M:  *+34 681 259 532* <+34%20681%20259%20532>
>>> E:  *steve.ha...@tmlep.com* 
>>> W:  *www.tmlep.com*
>>> 
>>>  [image:
>>> TMLEP | The Medico-Legal Experts Practice]
>>> 
>>> Consider the environment. Do you really need to print this email?
>>> TMLE Limited is a company registered in England and Wales under number
>>> 08092743. The company's registered office is The Chestnuts, Brewers
>>> End, Takeley, Essex CM22 6QJ United Kingdom.
>>>
>>> This message contains confidential information and is intended only for
>>> the intended recipients. If you are not an intended recipient you should
>>> not disseminate, distribute or copy this e-mail. Please notify the sender
>>> immediately by e-mail if you have received this e-mail by mistake and
>>> delete this e-mail from your system. E-mail transmission cannot be
>>> guaranteed to be secure or error-free as information could be intercepted,
>>> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
>>> The sender therefore does not accept liability for any errors or omissions
>>> in the contents of this message, which arise as a result of e-mail
>>> transmission. If verification is required please request a hard-copy
>>> version.
>>>
>>> TMLEP may monitor email traffic data and also the content of emails for
>>> compliance purposes and to protect its business.
>>>
>>>
>
> --
>
> Look after your data, and your database will look after you. -- Simon Riggs
>
> Sheldon E. Strauch
> *Data Architect, Data Services *
> *O* 312-676-1556
> *M* 224-723-3878
>
> *Enova International, Inc.*
> *This transmission is confidential and may be privileged or proprietary.
> If you are not the intended recipient, you are not authorized to use the
> information in this transmission in any way. Please inform the sender
> immediately if you have received this transmission in error and permanently
> delete and destroy the original and any copies of the information.*
>


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Change browser in MacOS

[Steve Hawes]

Sheldon,

The /usr/bin/firefox %URL% is the placeholder text that is used as an example 
for the browser command. I have tried with Chrome as my default browser and 
this works fine but I want to keep Safari as the default browser but use Chrome 
only for pgAdmin.

Following the reply I got from Richard Coleman and after a bit of Googling for 
the correct command I have found the syntax to be:

open -a “Google Chrome” %URL%

Hope this helps someone else as well.

Thanks
Steve


Steve Hawes
CIO
T: 020 3355 9796
M: +34 681 259 532
E: steve.ha...@tmlep.com
W: www.tmlep.com
TMLEP | The Medico-Legal Experts Practice
Consider the environment. Do you really need to print this email?
TMLE Limited is a company registered in England and Wales under number 
08092743. The company's registered office is The Chestnuts, Brewers End, 
Takeley, Essex CM22 6QJ United Kingdom.

This message contains confidential information and is intended only for the 
intended recipients. If you are not an intended recipient you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. E-mail transmission cannot be guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses. The sender therefore 
does not accept liability for any errors or omissions in the contents of this 
message, which arise as a result of e-mail transmission. If verification is 
required please request a hard-copy version.

TMLEP may monitor email traffic data and also the content of emails for 
compliance purposes and to protect its business.

From: "Strauch, Sheldon" 
Date: Tuesday, 8 January 2019 at 15:42
To: richard coleman 
Cc: Steve Hawes , "pgadmin-support@lists.postgresql.org" 

Subject: Re: Change browser in MacOS

Interestingly enough, I use Chrome exclusively and my Browser Command is 
configured to: /usr/bin/firefox %URL%
When selecting New pgAdmin 4 Window... the new window opens in Chrome. Seeing 
as firefox is not even installed, I believe in the absence of a working command 
pgAdmin 4 reverts to OSX's default browser, which I do have configured to be 
chrome.

HTH!

On Tue, Jan 8, 2019 at 9:33 AM richard coleman 
mailto:rcoleman.ascen...@gmail.com>> wrote:
Steve,

Well I have mine set to launch chromium with this command:
chromium-browser %URL%

So I would imagine substituting the command to start chrome from the command 
line would suffice.

Just a thought,

rik.

On Tue, Jan 8, 2019 at 10:02 AM Steve Hawes 
mailto:steve.ha...@tmlep.com>> wrote:
Hi,

Can anyone help me with changing the browser used by pgAdmin in MacOS Mojave.

I have Google Chrome installed and can see that there is a box for entering the 
Browser Command in the pgAdmin configuration but I cannot work out the syntax 
for getting Chrome to launch instead of Safari. Any help appreciated.

Many thanks
Steve

Steve Hawes​

CIO


[X][cid:1682e178a07b43dd9c91]





T:

020 3355 9796

M:

+34 681 259 532

E:

steve.ha...@tmlep.com

W:

www.tmlep.com


[TMLEP | The Medico-Legal Experts 
Practice]


[cid:1682e178a07f49eec743]

Consider the environment. Do you really need to print this email?


TMLE Limited is a company registered in England and Wales under number 
08092743. The company's registered office is The Chestnuts, Brewers End, 
Takeley, Essex CM22 6QJ United Kingdom.

This message contains confidential information and is intended only for the 
intended recipients. If you are not an intended recipient you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. E-mail transmission cannot be guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses. The sender therefore 
does not accept liability for any errors or omissions in the contents of this 
message, which arise as a result of e-mail transmission. If verification is 
required please request a hard-copy version.

TMLEP may monitor email traffic data and also the content of emails for 
compliance purposes and to protect its business.





--

Look after your data, and your database will look after you. -- Simon Riggs

Sheldon E. Strauch
Data Architect, Data Services
O 312-676-1556
M 22

Re: Change browser in MacOS

[Patrick De Visschere]

Can someone tell were this command is saved, because I have to reenter it from 
time to time.

Regards,
P. De Visschere

> On 8 Jan 2019, at 17:10, Steve Hawes  wrote:
> 
> Sheldon,
>  
> The /usr/bin/firefox %URL% is the placeholder text that is used as an example 
> for the browser command. I have tried with Chrome as my default browser and 
> this works fine but I want to keep Safari as the default browser but use 
> Chrome only for pgAdmin. 
>  
> Following the reply I got from Richard Coleman and after a bit of Googling 
> for the correct command I have found the syntax to be:
>  
> open -a “Google Chrome” %URL%
>  
> Hope this helps someone else as well.
>  
> Thanks
> Steve
>  
> 
> Steve Hawes​
> CIO
> 
>  
> T:020 3355 9796 
> M:+34 681 259 532 
> E:steve.ha...@tmlep.com 
> W:www.tmlep.com 
> 
>  Consider the environment. Do you really need to print 
> this email?
> TMLE Limited is a company registered in England and Wales under number 
> 08092743. The company's registered office is The Chestnuts, Brewers End, 
> Takeley, Essex CM22 6QJ United Kingdom.
> 
> This message contains confidential information and is intended only for the 
> intended recipients. If you are not an intended recipient you should not 
> disseminate, distribute or copy this e-mail. Please notify the sender 
> immediately by e-mail if you have received this e-mail by mistake and delete 
> this e-mail from your system. E-mail transmission cannot be guaranteed to be 
> secure or error-free as information could be intercepted, corrupted, lost, 
> destroyed, arrive late or incomplete, or contain viruses. The sender 
> therefore does not accept liability for any errors or omissions in the 
> contents of this message, which arise as a result of e-mail transmission. If 
> verification is required please request a hard-copy version. 
> 
> TMLEP may monitor email traffic data and also the content of emails for 
> compliance purposes and to protect its business. 
> 
> From: "Strauch, Sheldon" mailto:sstra...@enova.com>>
> Date: Tuesday, 8 January 2019 at 15:42
> To: richard coleman  >
> Cc: Steve Hawes mailto:steve.ha...@tmlep.com>>, 
> "pgadmin-support@lists.postgresql.org 
> " 
>  >
> Subject: Re: Change browser in MacOS
>  
> Interestingly enough, I use Chrome exclusively and my Browser Command is 
> configured to: /usr/bin/firefox %URL%
> When selecting New pgAdmin 4 Window... the new window opens in Chrome. Seeing 
> as firefox is not even installed, I believe in the absence of a working 
> command pgAdmin 4 reverts to OSX's default browser, which I do have 
> configured to be chrome.
>  
> HTH!
>  
> On Tue, Jan 8, 2019 at 9:33 AM richard coleman  > wrote:
> Steve,  
>  
> Well I have mine set to launch chromium with this command:
> chromium-browser %URL%
>  
> So I would imagine substituting the command to start chrome from the command 
> line would suffice.
>  
> Just a thought, 
>  
> rik.  
>  
> On Tue, Jan 8, 2019 at 10:02 AM Steve Hawes  > wrote:
> Hi,
>  
> Can anyone help me with changing the browser used by pgAdmin in MacOS Mojave.
>  
> I have Google Chrome installed and can see that there is a box for entering 
> the Browser Command in the pgAdmin configuration but I cannot work out the 
> syntax for getting Chrome to launch instead of Safari. Any help appreciated.
>  
> Many thanks
> Steve
>  
> Steve Hawes​
> CIO
> 
>  
> T: 
> 020 3355 9796 
> M: 
> +34 681 259 532 
> E: 
> steve.ha...@tmlep.com 
> W: 
> www.tmlep.com 
> 
>   
>  
> 
> 
> Consider the environment. Do you really need to print this email?
> TMLE Limited is a company registered in England and Wales under number 
> 08092743. The company's registered office is The Chestnuts, Brewers End, 
> Takeley, Essex CM22 6QJ United Kingdom.
> 
> This message contains confidential information and is intended only for the 
> intended recipients. If you are not an intended recipient you should not 
> disseminate, distribute or copy this e-mail. Please notify the sender 
> immediately by e-mail if you have received this e-mail by mistake and delete 
> this e-mail from your system. E-mail transmission cannot be guaranteed to be 
> secure or error-free as information could be 

Re: Change browser in MacOS

[Dave Page]

On Tue, Jan 8, 2019 at 9:45 PM Patrick De Visschere 
wrote:

> Can someone tell were this command is saved, because I have to reenter it
> from time to time.
>

~/Library/Preferences/org.pgadmin.pgadmin4.plist on macOS.


> On 8 Jan 2019, at 17:10, Steve Hawes  wrote:
>
> Sheldon,
>
> The /usr/bin/firefox %URL% is the placeholder text that is used as an
> example for the browser command. I have tried with Chrome as my default
> browser and this works fine but I want to keep Safari as the default
> browser but use Chrome only for pgAdmin.
>
> Following the reply I got from Richard Coleman and after a bit of Googling
> for the correct command I have found the syntax to be:
>
> open -a “Google Chrome” %URL%
>
> Hope this helps someone else as well.
>
> Thanks
> Steve
>
>
> Steve Hawes
> CIO 
>
> T:  *020 3355 9796* <020%203355%209796>
> M:  *+34 681 259 532* <+34%20681%20259%20532>
> E:  *steve.ha...@tmlep.com* 
> W:  *www.tmlep.com*  
> 
>  Consider the environment. Do you really need to print
> this email?
> TMLE Limited is a company registered in England and Wales under number
> 08092743. The company's registered office is The Chestnuts, Brewers
> End, Takeley, Essex CM22 6QJ United Kingdom.
>
> This message contains confidential information and is intended only for
> the intended recipients. If you are not an intended recipient you should
> not disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system. E-mail transmission cannot be
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
> The sender therefore does not accept liability for any errors or omissions
> in the contents of this message, which arise as a result of e-mail
> transmission. If verification is required please request a hard-copy
> version.
>
> TMLEP may monitor email traffic data and also the content of emails for
> compliance purposes and to protect its business.
>
> *From: *"Strauch, Sheldon" 
> *Date: *Tuesday, 8 January 2019 at 15:42
> *To: *richard coleman 
> *Cc: *Steve Hawes , "
> pgadmin-support@lists.postgresql.org" <
> pgadmin-support@lists.postgresql.org>
> *Subject: *Re: Change browser in MacOS
>
> Interestingly enough, I use Chrome exclusively and my Browser Command is
> configured to: */usr/bin/firefox %URL%*
> When selecting *New pgAdmin 4 Window...* the new window opens in Chrome.
> Seeing as firefox is not even installed, I believe in the absence of a
> working command pgAdmin 4 reverts to OSX's default browser, which I do have
> configured to be chrome.
>
> HTH!
>
> On Tue, Jan 8, 2019 at 9:33 AM richard coleman <
> rcoleman.ascen...@gmail.com> wrote:
>
> Steve,
>
> Well I have mine set to launch chromium with this command:
>
> chromium-browser %URL%
>
>
> So I would imagine substituting the command to start chrome from the
> command line would suffice.
>
> Just a thought,
>
> rik.
>
> On Tue, Jan 8, 2019 at 10:02 AM Steve Hawes  wrote:
>
> Hi,
>
> Can anyone help me with changing the browser used by pgAdmin in MacOS
> Mojave.
>
> I have Google Chrome installed and can see that there is a box for
> entering the Browser Command in the pgAdmin configuration but I cannot work
> out the syntax for getting Chrome to launch instead of Safari. Any help
> appreciated.
>
> Many thanks
> Steve
>
> *Steve Hawes*
> *CIO*
> 
>
> *T: *
> *020 3355 9796 <020%203355%209796>*
> *M: *
> *+34 681 259 532 <+34%20681%20259%20532>*
> *E: *
> *steve.ha...@tmlep.com *
> *W: *
> *www.tmlep.com
> *
> 
> 
> 
> Consider the environment. Do you really need to print this email?
> TMLE Limited is a company registered in England and Wales under number
> 08092743. The company's registered office is The Chestnuts, Brewers
> End, Takeley, Essex CM22 6QJ United Kingdom.
>
> This message contains confidential information and is intended only for
> the intended recipients. If you are not an intended recipient you should
> not disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system. E-mail transmission cannot be
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
> The sender therefore does not acc

Re: Import/Export failure due to UTF-8 error in pgAdmin4 but not in pgAdmin3

[Dave Page]

Hi

On Tue, Jan 8, 2019 at 7:32 PM richard coleman
 wrote:
>
> Dave,
>
> I would imagine Nanina would be in a better position to provide you with 
> problematic import/export data in the short term.  I don't tend to 
> import/export that often these days, preferring to use SQL statements for 
> most things short of a full backup/restore (in my case I've found it to be 
> much less picky). As mentioned previously, in my experience the characters 
> that tend to trip up pgAdmin4 are Windows special characters.  I would 
> imagine the upper Windows-1252 character set as being particularly 
> problematic for pgAdmin4 if it is expecting proper UTF-8 (i.e. 
> ŒœŠšŸŽžƒˆ˜–—‘’‚“”„†‡•…‰‹›€™).  This would explain why Windows ODBC, .Net, and 
> pSQL have no problems dealing with the data.  I would imagine if it the 
> database was set up with  ENCODING =  'WIN1252' then postgreSQL would do the 
> translation into UTF-8 for pgAdmin4, but since it isn't postgreSQL can't 
> provide pgAdmin4 with any help.

Right - and that's kinda the point. PostgreSQL is a database that is
designed to enforce integrity rules on your data, whether those be
around encoding, or table constraints, strong typing, foreign keys
etc. Those strengths are amongst the reasons most of us chose it in
the first place, rather than one of the NoSQL databases that are
usually much more forgiving in many respects.

> It's up to pgAdmin4 to deal with the otherwise valid data appropriately.

How can it? If there is no encoding specified (because you're using
SQL_ASCII, with values > 127) the behaviour is undefined by
definition. Any attempts to deal with such data will be hit and miss
because there is no possible way for pgAdmin to know how the data is
supposed to be interpreted. You know your data is Win1252 encoded, but
for all pgAdmin knows, it could be Win1253.

The best option is to use the correct encoding for the database, or if
you have data that really doesn't conform to any encoding standard,
use the bytea datatype.

Anyway, I've said my piece. I'll go investigate the workaround in a
moment and report back.

> I hope your workaround pans out, until then I will spend my time at the psql 
> prompt, or if the data is needed elsewhere run the two functions I had 
> included previously to identify and remove the offensive characters.
>
> Here's the create database script for one of my databases, perhaps it can 
> shed some light (it was originally an 8.3 postgreSQL database {long before my 
> time here, currently running under postgreSQL 10.x} and apparently back then 
> it defaulted to creating SQL_ASCII encoded databases on Windows).
>
>> CREATE DATABASE tms_production
>> WITH
>> OWNER = local_user
>> ENCODING = 'SQL_ASCII'
>> LC_COLLATE = 'English_United States.1252'
>> LC_CTYPE = 'English_United States.1252'
>> TABLESPACE = pg_default
>> CONNECTION LIMIT = -1;
>> ALTER DATABASE tms_production
>> SET default_transaction_read_only TO off;
>> ALTER DATABASE tms_production
>> SET client_encoding TO sql_ascii;
>> ALTER DATABASE tms_production
>> SET standard_conforming_strings TO off;

Thanks!


> On Tue, Jan 8, 2019 at 8:37 AM Dave Page  wrote:
>>
>> Hi Rik
>>
>> On Tue, Jan 8, 2019 at 6:53 PM richard coleman
>>  wrote:
>> >
>> > Dave,
>> >
>> > Thanks for continuing this discussion, but I think you misunderstand the 
>> > situation.  I am storing valid non-UTF8 data in a SQL_ASCII encoded 
>> > postgreSQL database (please re-read what I had previously written). This 
>> > is why psql has NO problem dealing with it.  This is also why Windows ODBC 
>> > and .Net applications have NO problem dealing with it.  In fact the most 
>> > common character that pgAdmin4 crashes on is the Windows smart quote.  So 
>> > to reiterate, I am using valid non-UTF8 characters in a SQL_ASCII 
>> > database.  This is a supported configuration for postgreSQL.  The issue 
>> > seems to be that pgAdmin4 is assuming  UTF8 data and 
>> > crashing/failing/throwing errors when it encounters invalid UTF8 
>> > characters.
>> >
>> > I hope I have made the situation a little bit clearer.
>>
>> Well psql is failing to deal with it *in this case*, as that's what is
>> doing the \copy in the import/export tool.
>>
>> In other cases (i.e. the ones where pgAdmin sees the data, such as
>> results in the query tool), the issue arises because Python and/or
>> Javascript (and by extension pgAdmin) may barf on data encoded in a
>> way they don't recognise. That's why the PostgreSQL docs say to only
>> use ASCII data in SQL_ASCII databases - the behaviour is undefined,
>> and as a result may either not render properly or may crash or error
>> on non-ASCII data.
>>
>> Anyhoo, I expect to have a little time after dinner shortly so I'll
>> try out the workaround I thought of earlier to see if it helps (I
>> doubt it'll be a panacea, but it may help in some cases).
>>
>> By any chance do you have a test case you can share with me that
>> refuses to export 

Re: Import/Export failure due to UTF-8 error in pgAdmin4 but not in pgAdmin3

[Dave Page]

On Tue, Jan 8, 2019 at 8:55 PM Nanina Tron  wrote:
>
>
> Hi,
>
> yes thank you I will scan the table so at least I will see the 'bad' 
> characters. We will see how many there are.
> Sorry, i forgot to append the data.

Thanks. Did that include the "bad" data? I can load it just fine into
a SQL_ASCII database (which I'd expect, as there's no encoding
checks), or a UTF-8 database, and I can successfully export the table
in both cases.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Change browser in MacOS

[Patrick De Visschere]

Dave,

Thanks but this is my ~/Library/Preferences/org.pgadmin.pgadmin4.plist with the 
Browser command filled in
(I have removed the content of the data tags)


http://www.apple.com/DTDs/PropertyList-1.0.dtd";>


Browser.Geometry



Browser.LastSaveLocation

Browser.WindowState



NSNavLastRootDirectory

NSNavPanelExpandedSizeForSaveMode

NSStatusItem Preferred Position Item-0




I don’t see the command.

Regards,

P. De Visschere

> On 8 Jan 2019, at 17:48, Dave Page  wrote:
> 
> 
> 
> On Tue, Jan 8, 2019 at 9:45 PM Patrick De Visschere  > wrote:
> Can someone tell were this command is saved, because I have to reenter it 
> from time to time.
> 
> ~/Library/Preferences/org.pgadmin.pgadmin4.plist on macOS.
>  
>> On 8 Jan 2019, at 17:10, Steve Hawes > > wrote:
>> 
>> Sheldon,
>>  
>> The /usr/bin/firefox %URL% is the placeholder text that is used as an 
>> example for the browser command. I have tried with Chrome as my default 
>> browser and this works fine but I want to keep Safari as the default browser 
>> but use Chrome only for pgAdmin. 
>>  
>> Following the reply I got from Richard Coleman and after a bit of Googling 
>> for the correct command I have found the syntax to be:
>>  
>> open -a “Google Chrome” %URL%
>>  
>> Hope this helps someone else as well.
>>  
>> Thanks
>> Steve
>>  
>> 
>> Steve Hawes
>> CIO
>> 
>>  
>> T:   020 3355 9796 
>> M:   +34 681 259 532 
>> E:   steve.ha...@tmlep.com 
>> W:   www.tmlep.com 
>> 
>> Consider the environment. Do you really need to print 
>> this email?
>> TMLE Limited is a company registered in England and Wales under number 
>> 08092743. The company's registered office is The Chestnuts, Brewers End, 
>> Takeley, Essex CM22 6QJ United Kingdom.
>> 
>> This message contains confidential information and is intended only for the 
>> intended recipients. If you are not an intended recipient you should not 
>> disseminate, distribute or copy this e-mail. Please notify the sender 
>> immediately by e-mail if you have received this e-mail by mistake and delete 
>> this e-mail from your system. E-mail transmission cannot be guaranteed to be 
>> secure or error-free as information could be intercepted, corrupted, lost, 
>> destroyed, arrive late or incomplete, or contain viruses. The sender 
>> therefore does not accept liability for any errors or omissions in the 
>> contents of this message, which arise as a result of e-mail transmission. If 
>> verification is required please request a hard-copy version. 
>> 
>> TMLEP may monitor email traffic data and also the content of emails for 
>> compliance purposes and to protect its business. 
>> 
>> From: "Strauch, Sheldon" mailto:sstra...@enova.com>>
>> Date: Tuesday, 8 January 2019 at 15:42
>> To: richard coleman > >
>> Cc: Steve Hawes mailto:steve.ha...@tmlep.com>>, 
>> "pgadmin-support@lists.postgresql.org 
>> " 
>> > >
>> Subject: Re: Change browser in MacOS
>>  
>> Interestingly enough, I use Chrome exclusively and my Browser Command is 
>> configured to: /usr/bin/firefox %URL%
>> When selecting New pgAdmin 4 Window... the new window opens in Chrome. 
>> Seeing as firefox is not even installed, I believe in the absence of a 
>> working command pgAdmin 4 reverts to OSX's default browser, which I do have 
>> configured to be chrome.
>>  
>> HTH!
>>  
>> On Tue, Jan 8, 2019 at 9:33 AM richard coleman > > wrote:
>> Steve,  
>>  
>> Well I have mine set to launch chromium with this command:
>> chromium-browser %URL%
>>  
>> So I would imagine substituting the command to start chrome from the command 
>> line would suffice.
>>  
>> Just a thought, 
>>  
>> rik.  
>>  
>> On Tue, Jan 8, 2019 at 10:02 AM Steve Hawes > > wrote:
>> Hi,
>>  
>> Can anyone help me with changing the browser used by pgAdmin in MacOS Mojave.
>>  
>> I have Google Chrome installed and can see that there is a box for entering 
>> the Browser Command in the pgAdmin configuration but I cannot work out the 
>> syntax for getting Chrome to launch instead of Safari. Any help appreciated.
>>  
>> Many thanks
>> Steve
>>  
>> Steve Hawes
>> CIO
>> 
>>  
>> T: 
>> 020 3355 9796 
>> M: 
>> +34 681 259 532 
>> E: 
>> steve.ha...@tmlep.com 
>> W: 
>> www.tmlep.com 
>> 
>>  
>>  
>> 

Re: Import/Export failure due to UTF-8 error in pgAdmin4 but not in pgAdmin3

[Doug Easterbrook]

https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html

Smart quotes are not ascii.   They are Unicode, strictly speaking .

We’ve Postgres reject  putting such stuff into the database using anything .



Sent from my iPad

> On Jan 8, 2019, at 9:23 AM, richard coleman  
> wrote:
> 
> Dave, 
> 
> Thanks for continuing this discussion, but I think you misunderstand the 
> situation.  I am storing valid non-UTF8 data in a SQL_ASCII encoded 
> postgreSQL database (please re-read what I had previously written). This is 
> why psql has NO problem dealing with it.  This is also why Windows ODBC and 
> .Net applications have NO problem dealing with it.  In fact the most common 
> character that pgAdmin4 crashes on is the Windows smart quote.  So to 
> reiterate, I am using valid non-UTF8 characters in a SQL_ASCII database.  
> This is a supported configuration for postgreSQL.  The issue seems to be that 
> pgAdmin4 is assuming  UTF8 data and crashing/failing/throwing errors when it 
> encounters invalid UTF8 characters.
> 
> I hope I have made the situation a little bit clearer.
> 
> Thanks again, 
> 
> rik. 
> 
>> On Tue, Jan 8, 2019 at 12:29 AM Dave Page  wrote:
>> Hi
>> 
>> On Tue, Jan 8, 2019 at 12:47 AM richard coleman
>>  wrote:
>> >
>> > Dave,
>> >
>> > Thanks for taking the time to respond, but I don't see anywhere that 
>> > SQL_ASCII is recommended against doing. Here's the documentation listing 
>> > the supported encoding schemas: 
>> > https://www.postgresql.org/docs/current/multibyte.html .
>> >
>> > The only caveats listed for SQL_ASCII are:
>> >>
>> >> In most cases, if you are working with any non-ASCII data, it is unwise 
>> >> to use the SQL_ASCII setting because PostgreSQL will be unable to help 
>> >> you by converting or validating non-ASCII characters.
>> 
>> You highlighted it below: "If the client character set is defined as
>> SQL_ASCII, encoding conversion is disabled, regardless of the server's
>> character set. Just as for the server, use of SQL_ASCII is unwise
>> unless you are working with all-ASCII data"
>> 
>> You're using UTF-8 data, not ASCII, which it says is unwise because
>> conversion won't take place (and consequently, neither will
>> validation). I don't see how one could read that and not take it as
>> 
>> You are running into exactly that problem; and it's visible when
>> working with technologies that are strict about following encoding
>> rules - in this case, psql when pgAdmin shells out to it.
>> 
>> I did think of one possible quick fix this morning which I'll look
>> into, but as I noted before; it's a workaround, and the real problem
>> is storing un-validated UTF-8 data in a SQL_ASCII database.
>> 
>> > Or, a reminder that postgreSQL can't help with any conversions you might 
>> > want to do.
>> >
>> > Then there's this:
>> >>
>> >> PostgreSQL will allow superusers to create databases with SQL_ASCII 
>> >> encoding even when LC_CTYPE is not C or POSIX. As noted above, SQL_ASCII 
>> >> does not enforce that the data stored in the database has any particular 
>> >> encoding, and so this choice poses risks of locale-dependent misbehavior. 
>> >> Using this combination of settings is deprecated and may someday be 
>> >> forbidden altogether.
>> >
>> >
>> > A note that you can currently choose incompatible settings, but probably 
>> > can't in the future.
>> >
>> > And finally there's this bit of advice:
>> >>
>> >> If the client character set is defined as SQL_ASCII, encoding conversion 
>> >> is disabled, regardless of the server's character set. Just as for the 
>> >> server, use of SQL_ASCII is unwise unless you are working with all-ASCII 
>> >> data[emphasis mine].
>> >
>> >
>> > Which is just a reiteration of the first caveat, that if you are using 
>> > SQL_ASCII the database won't perform any conversions on your behalf.
>> >
>> > That is hardly a recommendation against using that supported encoding 
>> > scheme.  The fact that the psql command prompt, among others, works with 
>> > it without issue, is an indication that the problem lies in pgAdmin4 (and 
>> > I would guess the reliance of python on UTF8) than an issue with the 
>> > database itself.  pgAdmin4 needs to check for and more gracefully handle 
>> > valid postgreSQL data that might happen to be not UTF8 compliant.
>> >
>> > Until then, I will have to periodically scan and clean for bad UTF8 data 
>> > to keep pgAdmin4 (and other JDBC dependent code) happy.  The legacy 
>> > enterprise .Net applications that depend on it prohibit converting it to 
>> > UTF8 (or anything else for that matter).
>> >
>> > Just my $0.02,
>> >
>> > rik.
>> >
>> >
>> > On Mon, Jan 7, 2019 at 1:27 PM Dave Page  wrote:
>> >>
>> >> Hi
>> >>
>> >> On Mon, Jan 7, 2019 at 11:30 PM richard coleman
>> >>  wrote:
>> >> >
>> >> > Dave,
>> >> >
>> >> > I can't speak to Nania's specific issue, but I believe it's a pgAdmin4 
>> >> > specific problem, at least in so far as SQL_ASCII is concerned.  I say 
>> >> > this because I can usually wor

Re: Import/Export failure due to UTF-8 error in pgAdmin4 but not in pgAdmin3

[richard coleman]

Doug,

Hi.  Is this a typo?

We’ve Postgres reject  putting such stuff into the database using anything .


PostgreSQL allow *any text* into a column if the database has been set to
use SQL_ASCII as the encoding. This was the default encoding on Windows
machines, a long long time ago.  All that setting the encoding to SQ:_ASCII
means is that postgreSQL *won't *do any translations between character
encoding for you.  We are storing what I believe is Windows-1252 characters
in the database.  The immediate problem (at least mine in so far as
pgAdmin4 is concerned) is that non-UTF8 characters (like smart quotes) are
handled *without* a problem by psql, .Net, and Windows ODBC (and under
pgAdmin3) but cause pgAdmin4 to crash/fail/thow errors.  The only way to
get pgAdmin4 to behave is to locate and remove the offending characters.
My guess is that this is due to it's python underpinnings and the
expectation that the database would correctly translate the data into valid
UTF8.  It is my belief that it should handle such *valid* postgreSQL data
better than it currently does.  At least as well as it's predecessor
pgAdmin3 did.

Just my $0.02,

rik.


On Tue, Jan 8, 2019 at 3:56 PM Doug Easterbrook  wrote:

> https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
>
> Smart quotes are not ascii.   They are Unicode, strictly speaking .
>
> We’ve Postgres reject  putting such stuff into the database using anything
> .
>
>
>
> Sent from my iPad
>
> On Jan 8, 2019, at 9:23 AM, richard coleman 
> wrote:
>
> Dave,
>
> Thanks for continuing this discussion, but I think you misunderstand the
> situation.  I am storing *valid* *non-UTF8* data in a SQL_ASCII encoded
> postgreSQL database (please re-read what I had previously written). This is
> why psql has *NO* problem dealing with it.  This is also why Windows ODBC
> and .Net applications have *NO* problem dealing with it.  In fact the
> most common character that pgAdmin4 crashes on is the Windows *smart
> quote*.  So to reiterate, I am using *valid **non-UTF8* characters in a
> SQL_ASCII database.  This is a supported configuration for postgreSQL.  The
> issue seems to be that pgAdmin4 is *assuming * UTF8 data and
> crashing/failing/throwing errors when it encounters invalid UTF8 characters.
>
> I hope I have made the situation a little bit clearer.
>
> Thanks again,
>
> rik.
>
> On Tue, Jan 8, 2019 at 12:29 AM Dave Page  wrote:
>
>> Hi
>>
>> On Tue, Jan 8, 2019 at 12:47 AM richard coleman
>>  wrote:
>> >
>> > Dave,
>> >
>> > Thanks for taking the time to respond, but I don't see anywhere that
>> SQL_ASCII is recommended against doing. Here's the documentation listing
>> the supported encoding schemas:
>> https://www.postgresql.org/docs/current/multibyte.html .
>> >
>> > The only caveats listed for SQL_ASCII are:
>> >>
>> >> In most cases, if you are working with any non-ASCII data, it is
>> unwise to use the SQL_ASCII setting because PostgreSQL will be unable to
>> help you by converting or validating non-ASCII characters.
>>
>> You highlighted it below: "If the client character set is defined as
>> SQL_ASCII, encoding conversion is disabled, regardless of the server's
>> character set. Just as for the server, use of SQL_ASCII is unwise
>> unless you are working with all-ASCII data"
>>
>> You're using UTF-8 data, not ASCII, which it says is unwise because
>> conversion won't take place (and consequently, neither will
>> validation). I don't see how one could read that and not take it as
>>
>> You are running into exactly that problem; and it's visible when
>> working with technologies that are strict about following encoding
>> rules - in this case, psql when pgAdmin shells out to it.
>>
>> I did think of one possible quick fix this morning which I'll look
>> into, but as I noted before; it's a workaround, and the real problem
>> is storing un-validated UTF-8 data in a SQL_ASCII database.
>>
>> > Or, a reminder that postgreSQL can't help with any conversions you
>> might want to do.
>> >
>> > Then there's this:
>> >>
>> >> PostgreSQL will allow superusers to create databases with SQL_ASCII
>> encoding even when LC_CTYPE is not C or POSIX. As noted above, SQL_ASCII
>> does not enforce that the data stored in the database has any particular
>> encoding, and so this choice poses risks of locale-dependent misbehavior.
>> Using this combination of settings is deprecated and may someday be
>> forbidden altogether.
>> >
>> >
>> > A note that you can currently choose incompatible settings, but
>> probably can't in the future.
>> >
>> > And finally there's this bit of advice:
>> >>
>> >> If the client character set is defined as SQL_ASCII, encoding
>> conversion is disabled, regardless of the server's character set. Just as
>> for the server, use of SQL_ASCII is unwise unless you are working with
>> all-ASCII data[emphasis mine].
>> >
>> >
>> > Which is just a reiteration of the first caveat, that if you are using
>> SQL_ASCII the database won't perform any conversions on your behalf.
>>

Re: Import/Export failure due to UTF-8 error in pgAdmin4 but not in pgAdmin3

[Doug Easterbrook]

Had a rethink of this.  We had sql ascii databases with non ascii data in 
it.   When converting that data to utf8 and sticking into Postgres, all that 
windows extended characters could not be used unless converted to utf8 before 
hand.

It may be that your case depends 9n the character coding issued by the client 
as it overrides the database encoding to some extent.

So.. you may want to just give it up and go utf8 anyway,It sets you up for 
the future.

Or go get pgadmin 3 from bigsql ...  it will talk to Postgres 10 for sure and I 
think it talks to Postgres 11.  I use both pgadmin 3 and 4 since there are 
some things that both do well. 

Sent from my iPad

> On Jan 8, 2019, at 5:44 PM, richard coleman  
> wrote:
> 
> Doug, 
> 
> Hi.  Is this a typo?
> 
>> We’ve Postgres reject  putting such stuff into the database using anything .
> 
> PostgreSQL allow any text into a column if the database has been set to use 
> SQL_ASCII as the encoding. This was the default encoding on Windows machines, 
> a long long time ago.  All that setting the encoding to SQ:_ASCII means is 
> that postgreSQL won't do any translations between character encoding for you. 
>  We are storing what I believe is Windows-1252 characters in the database.  
> The immediate problem (at least mine in so far as pgAdmin4 is concerned) is 
> that non-UTF8 characters (like smart quotes) are handled without a problem by 
> psql, .Net, and Windows ODBC (and under pgAdmin3) but cause pgAdmin4 to 
> crash/fail/thow errors.  The only way to get pgAdmin4 to behave is to locate 
> and remove the offending characters.  My guess is that this is due to it's 
> python underpinnings and the expectation that the database would correctly 
> translate the data into valid UTF8.  It is my belief that it should handle 
> such valid postgreSQL data better than it currently does.  At least as well 
> as it's predecessor pgAdmin3 did.
> 
> Just my $0.02, 
> 
> rik.
> 
> 
>> On Tue, Jan 8, 2019 at 3:56 PM Doug Easterbrook  wrote:
>> https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
>> 
>> Smart quotes are not ascii.   They are Unicode, strictly speaking .
>> 
>> We’ve Postgres reject  putting such stuff into the database using anything .
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Jan 8, 2019, at 9:23 AM, richard coleman  
>>> wrote:
>>> 
>>> Dave, 
>>> 
>>> Thanks for continuing this discussion, but I think you misunderstand the 
>>> situation.  I am storing valid non-UTF8 data in a SQL_ASCII encoded 
>>> postgreSQL database (please re-read what I had previously written). This is 
>>> why psql has NO problem dealing with it.  This is also why Windows ODBC and 
>>> .Net applications have NO problem dealing with it.  In fact the most common 
>>> character that pgAdmin4 crashes on is the Windows smart quote.  So to 
>>> reiterate, I am using valid non-UTF8 characters in a SQL_ASCII database.  
>>> This is a supported configuration for postgreSQL.  The issue seems to be 
>>> that pgAdmin4 is assuming  UTF8 data and crashing/failing/throwing errors 
>>> when it encounters invalid UTF8 characters.
>>> 
>>> I hope I have made the situation a little bit clearer.
>>> 
>>> Thanks again, 
>>> 
>>> rik. 
>>> 
 On Tue, Jan 8, 2019 at 12:29 AM Dave Page  wrote:
 Hi
 
 On Tue, Jan 8, 2019 at 12:47 AM richard coleman
  wrote:
 >
 > Dave,
 >
 > Thanks for taking the time to respond, but I don't see anywhere that 
 > SQL_ASCII is recommended against doing. Here's the documentation listing 
 > the supported encoding schemas: 
 > https://www.postgresql.org/docs/current/multibyte.html .
 >
 > The only caveats listed for SQL_ASCII are:
 >>
 >> In most cases, if you are working with any non-ASCII data, it is unwise 
 >> to use the SQL_ASCII setting because PostgreSQL will be unable to help 
 >> you by converting or validating non-ASCII characters.
 
 You highlighted it below: "If the client character set is defined as
 SQL_ASCII, encoding conversion is disabled, regardless of the server's
 character set. Just as for the server, use of SQL_ASCII is unwise
 unless you are working with all-ASCII data"
 
 You're using UTF-8 data, not ASCII, which it says is unwise because
 conversion won't take place (and consequently, neither will
 validation). I don't see how one could read that and not take it as
 
 You are running into exactly that problem; and it's visible when
 working with technologies that are strict about following encoding
 rules - in this case, psql when pgAdmin shells out to it.
 
 I did think of one possible quick fix this morning which I'll look
 into, but as I noted before; it's a workaround, and the real problem
 is storing un-validated UTF-8 data in a SQL_ASCII database.
 
 > Or, a reminder that postgreSQL can't help with any conversions you might 
 > want to do.
 >
 > Then there's this:
 >>
 >>

Re: Import/Export failure due to UTF-8 error in pgAdmin4 but not in pgAdmin3

[Linus Hicks]

I'm not a PostgreSQL expert, but especially since python plays a role here,
the system language must be taken into account. If you are wanting no
conversion to be done on your "ASCII" data, then you will probably have to
go through special hoops.

On Tue, Jan 8, 2019, 5:19 PM Doug Easterbrook  Had a rethink of this.  We had sql ascii databases with non ascii data
> in it.   When converting that data to utf8 and sticking into Postgres, all
> that windows extended characters could not be used unless converted to utf8
> before hand.
>
> It may be that your case depends 9n the character coding issued by the
> client as it overrides the database encoding to some extent.
>
> So.. you may want to just give it up and go utf8 anyway,It sets you up
> for the future.
>
> Or go get pgadmin 3 from bigsql ...  it will talk to Postgres 10 for sure
> and I think it talks to Postgres 11.  I use both pgadmin 3 and 4 since
> there are some things that both do well.
>
> Sent from my iPad
>
> On Jan 8, 2019, at 5:44 PM, richard coleman 
> wrote:
>
> Doug,
>
> Hi.  Is this a typo?
>
> We’ve Postgres reject  putting such stuff into the database using anything
>> .
>
>
> PostgreSQL allow *any text* into a column if the database has been set to
> use SQL_ASCII as the encoding. This was the default encoding on Windows
> machines, a long long time ago.  All that setting the encoding to SQ:_ASCII
> means is that postgreSQL *won't *do any translations between character
> encoding for you.  We are storing what I believe is Windows-1252 characters
> in the database.  The immediate problem (at least mine in so far as
> pgAdmin4 is concerned) is that non-UTF8 characters (like smart quotes) are
> handled *without* a problem by psql, .Net, and Windows ODBC (and under
> pgAdmin3) but cause pgAdmin4 to crash/fail/thow errors.  The only way to
> get pgAdmin4 to behave is to locate and remove the offending characters.
> My guess is that this is due to it's python underpinnings and the
> expectation that the database would correctly translate the data into valid
> UTF8.  It is my belief that it should handle such *valid* postgreSQL data
> better than it currently does.  At least as well as it's predecessor
> pgAdmin3 did.
>
> Just my $0.02,
>
> rik.
>
>
> On Tue, Jan 8, 2019 at 3:56 PM Doug Easterbrook  wrote:
>
>> https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
>>
>> Smart quotes are not ascii.   They are Unicode, strictly speaking .
>>
>> We’ve Postgres reject  putting such stuff into the database using
>> anything .
>>
>>
>>
>> Sent from my iPad
>>
>> On Jan 8, 2019, at 9:23 AM, richard coleman 
>> wrote:
>>
>> Dave,
>>
>> Thanks for continuing this discussion, but I think you misunderstand the
>> situation.  I am storing *valid* *non-UTF8* data in a SQL_ASCII encoded
>> postgreSQL database (please re-read what I had previously written). This is
>> why psql has *NO* problem dealing with it.  This is also why Windows
>> ODBC and .Net applications have *NO* problem dealing with it.  In fact
>> the most common character that pgAdmin4 crashes on is the Windows *smart
>> quote*.  So to reiterate, I am using *valid **non-UTF8* characters in a
>> SQL_ASCII database.  This is a supported configuration for postgreSQL.  The
>> issue seems to be that pgAdmin4 is *assuming * UTF8 data and
>> crashing/failing/throwing errors when it encounters invalid UTF8 characters.
>>
>> I hope I have made the situation a little bit clearer.
>>
>> Thanks again,
>>
>> rik.
>>
>> On Tue, Jan 8, 2019 at 12:29 AM Dave Page  wrote:
>>
>>> Hi
>>>
>>> On Tue, Jan 8, 2019 at 12:47 AM richard coleman
>>>  wrote:
>>> >
>>> > Dave,
>>> >
>>> > Thanks for taking the time to respond, but I don't see anywhere that
>>> SQL_ASCII is recommended against doing. Here's the documentation listing
>>> the supported encoding schemas:
>>> https://www.postgresql.org/docs/current/multibyte.html .
>>> >
>>> > The only caveats listed for SQL_ASCII are:
>>> >>
>>> >> In most cases, if you are working with any non-ASCII data, it is
>>> unwise to use the SQL_ASCII setting because PostgreSQL will be unable to
>>> help you by converting or validating non-ASCII characters.
>>>
>>> You highlighted it below: "If the client character set is defined as
>>> SQL_ASCII, encoding conversion is disabled, regardless of the server's
>>> character set. Just as for the server, use of SQL_ASCII is unwise
>>> unless you are working with all-ASCII data"
>>>
>>> You're using UTF-8 data, not ASCII, which it says is unwise because
>>> conversion won't take place (and consequently, neither will
>>> validation). I don't see how one could read that and not take it as
>>>
>>> You are running into exactly that problem; and it's visible when
>>> working with technologies that are strict about following encoding
>>> rules - in this case, psql when pgAdmin shells out to it.
>>>
>>> I did think of one possible quick fix this morning which I'll look
>>> into, but as I noted before; it's a workaround, and the real probl