Обсуждение: 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