Thread: Bug in exporting results to file

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
wasdropping a row without warning.  That row was being displayed within a pgadmin window and one of the columns did
havedata 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
nodefault method was selected or the local charset selected (probably utf-16 since this is on WinXP) the row would not
beexported to the file.
 

Shouldn't pgadmin generate a warning that all rows were not exported or abort the export process instead of silently
removingthe row?
 

Mike

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

Yes but it will take a little time.  I will post a backup that can be
restored but probably not till later on in the week.

Mike

On Mon, 2005-03-28 at 08:18, 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

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