Thread: viewing tables with bytea fields in 1.2.2 and 1.4b2
I'm not sure if this is something that has been discussed before. I did a archive search and didn't find anything... The problem I'm having is that I have a table with a bytea field that is used to store a file- not necessary large files, they could be but I saw this behavior with something where the table contained records with no more that 2Mb in the bytea field (and most of the bytea were empty). That behavior was that, I could NOT view the table. I thought it was just slow because of the data being read in but even after 30 minutes, the app was still hung. The database is 8.0.3 and I'm running on Slackware Linux 10.1. I was using 1.2.2 and tried 1.4b2 the clients are on the same box as the server. I just tried 1.2.2 in on Win2k and it actually did work (remotely even the internet with SSL- oh how I love pgadmin for THAT 1 feature but i digress). It takes awhile to load of course. I saw a similar respond on the Linux client working with another table that same's jpg images that were no larger than 10k. Oh and I have wxWidgets 2.6.1 installed. (wxWindows 2.4.2 appears to be installed as well). My question is what is the work around to view AND edit a table with "large" bytea fields. I already created a view that has all fields except the bytea but I can't insert records in a view. So you understand my process, I use pgadmin to insert/update some of the record data and then I have a loader script to slurp the file data into the database. It would NOT work for me to insert the complete record via script. I would think you really can't or **probably** would not manipulate byteas in pgadmin. Could there not be and option to "ignore" a bytea field(s) (i.e. a placeholder or some sort) so that you can insert, update, etc other record fields without having to wait for bytea field data? Thanks! -- Keith C. Perry, MS E.E. Director of Networks & Applications VCSN, Inc. http://vcsn.com ____________________________________ This email account is being host by: VCSN, Inc : http://vcsn.com
Keith C. Perry wrote: > > I would think you really can't or **probably** would not manipulate > byteas in pgadmin. Could there not be and option to "ignore" a bytea > field(s) (i.e. a placeholder or some sort) so that you can insert, > update, etc other record fields without having to wait for bytea > field data? I'll have a look at it for 1.4postBeta3; non-editing bytea seems reasonable. Regards, Andreas
Great. I'll work around it for now but dare I ask... do you have a timetable for the beta releases? I think I know the answer but you know I had to ask :) Quoting Andreas Pflug <pgadmin@pse-consulting.de>: > Keith C. Perry wrote: > > > > > > I would think you really can't or **probably** would not manipulate > > byteas in pgadmin. Could there not be and option to "ignore" a bytea > > field(s) (i.e. a placeholder or some sort) so that you can insert, > > update, etc other record fields without having to wait for bytea > > field data? > > I'll have a look at it for 1.4postBeta3; non-editing bytea seems reasonable. > > Regards, > Andreas > -- Keith C. Perry, MS E.E. Director of Networks & Applications VCSN, Inc. http://vcsn.com ____________________________________ This email account is being host by: VCSN, Inc : http://vcsn.com
Keith C. Perry wrote: > Great. I'll work around it for now but dare I ask... do you have a timetable > for the beta releases? I think I know the answer but you know I had to ask :) We're heading for *release* in-time with PostgreSQL 8.1, due end of this month or so. Regards, Andreas
Keith C. Perry wrote: > > I would think you really can't or **probably** would not > manipulate byteas in pgadmin. Could there not be and option to "ignore" a bytea > field(s) (i.e. a placeholder or some sort) so that you can insert, update, etc > other record fields without having to wait for bytea field data? I had a brief look at that issue, and I'm afraid this will remain unhandled for 1.4. I recorded it in BUGS.txt, so we won't forget to review it as soon as we have a little more time. We don't want to break things so short before release. Regards, Andreas