From: | "Hiroshi Saito" <saito(at)inetrt(dot)skcapi(dot)co(dot)jp> |
---|---|
To: | "Andreas Pflug" <Andreas(dot)Pflug(at)web(dot)de>, "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> |
Cc: | <pgadmin-hackers(at)postgresql(dot)org> |
Subject: | Re: pgAdmin3 feature freeze? |
Date: | 2003-06-24 16:08:57 |
Message-ID: | 021d01c33a6a$ea9da450$1f324d80@w2k |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Weiping He | 2003-06-24 16:13:35 | Re: Translation HOWTO |
Previous Message | Jean-Michel POURE | 2003-06-24 16:07:11 | pgAdmin3 stack trace |