Re: [pgadmin-hackers] pgAdmin3 feature freeze?
Hi Andreas. I am sorry that my response is dull... I thought how pgadmin3 should handle LargeObject. There is the following three approach with pgsql-7.3 as the way of handling it. 1) It has the one related to the reference with column-OID. Then, the actual condition is pg_lageobject. This suggests the standard use of psql. 2) It has the one related to the reference with column-lo. column data by the definition of Type-lo This has been the property of the way of using it since the old days of ODBC-Driver. 3) It goes into column-bytea directly. This makes use with new ODBC possible. It thinks that it has a headache. Is there any thought? --- Though a topic strays, Dave. Usage Version7.3 following with ODBC. CREATE FUNCTION lo_in(cstring) RETURNS lo AS 'int4in' LANGUAGE 'internal' WITH (ISCACHABLE, ISSTRICT); CREATE FUNCTION lo_out(lo) RETURNS cstring AS 'int4out' LANGUAGE 'internal' WITH (ISCACHABLE, ISSTRICT); CREATE TYPE lo ( internallength = 4, externallength=10, input = lo_in, output = lo_out, alignment = int4, default = '', passedbyvalue ); And Cast is necessary to begin to lead OID. CREATE CAST (lo AS oid) WITHOUT FUNCTION; Regards, Hiroshi-Saito ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers] pgAdmin3 feature freeze?
Hi Andreas. From: Andreas Pflug [EMAIL PROTECTED] Hiroshi Saito wrote: Hi Andreas. I am sorry that my response is dull... I thought how pgadmin3 should handle LargeObject. There is the following three approach with pgsql-7.3 as the way of handling it. Hiroshi, pgAdmin3 doesn't handle blobs at the moment, because it doesn't work with data a lot. If a selected column contains lo or bytea, the string output of libpq is shown. This might not be pretty looking, but interpretation of a blob is up to an application. I don't see a way to handle this in a meaningful way for the tools we have in pgAdmin3 at the moment. This might change if we support some dump/restore or load functionality, but this is a feature of forthcoming versions. It was understood. With the material which I enjoy. Regards, Hiroshi-Saito ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] pgAdmin3 feature freeze?
It's rumoured that Jochem van Dieten once said: Dave Page wrote: So people - any more essential features? Shout now or forever hold your peace (well, until the next release anyhoo)!! Not essential, but I have some further requests: query dialogue: button to explain analyze Should be easy (I think). We already have explain. double click in tree: give user option to open property page, do nothing or view data There is an option already to select property page or expand node (which is probably your do nothing). dump/restore (Maybe as a plugin that uses pg_dump and pg_restore to reuse the existing functionality but has a clickety-click interface.) If this is done, it will reuse PostgreSQL code, however we already decided this was a v2 feature. Smarter use of connections If I connect to a database cluster and the initial database is the same as the database I am working in, why would pgAdmin 3 require 2 different connections? Just the way it evolved I guess. I can't see any immediate reason why it couldn't reuse the initial connection. (On a related note; will the disconnect feature make it into the beta?) I thought it was there already - I'll take a look. Regards, Dave ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgadmin-hackers] pgAdmin3 feature freeze?
Andreas Pflug wrote: Jochem van Dieten wrote: query dialogue: button to explain analyze Has been present in query window right from the start! I only see is a button to explain, not to explain anlayze. Jochem ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
