Finally got to this.
Attached is a database dump file creating using defaults in pgadmin. It has one table in the public schema with 3 rows
init. If you do a select * from export_lost, then File->export->choose local character set (I am using XP Pro with
U.S.codepage), the file exported will have the 1st and 3rd row in it.
The hex code of the offending character is 0641 (Arabic).
postgres 8.0.2 on XP Pro with (server?) encoding C and database encoding Unicode.
Mike
On Mon, Mar 28, 2005 at 02:18:40PM +0000, Andreas Pflug wrote:
> Mike G. wrote:
> >Hi,
> >
> >I read the faq about the problem where pgadmin won't display data if
> >it cannot convert the data due to an encoding issue.
> >
> >I have a table created under Latin1. When doing a select * from that
> >table and exporting the results to a file pgadmin was dropping a row
> >without warning. That row was being displayed within a pgadmin
> >window and one of the columns did have data in it that appeared to
> >not be converting correctly.
> >
> >By selecting the export encoding method of utf-8 and then exporting
> >the result that row would appear in the file. If no default method
> >was selected or the local charset selected (probably utf-16 since
> >this is on WinXP) the row would not be exported to the file.
> >
> >Shouldn't pgadmin generate a warning that all rows were not exported
> >or abort the export process instead of silently removing the row?
>
> I agree, pgAdmin shouldn't write garbage silently. Can you provide an
> example?
>
> Regards,
> Andreas
