[SQL] TEXT blob extraction in ecpg

2005-01-10 Thread none none
Does any one know how to properly extract a TEXT type blob (undefined char 
length) in ecpg (Linux system)?  We are converting our SQL from Informix to 
PostGres.  Informix had a specific struct defined and I believe handled the 
dynamic memory allocation, but I cannot find any guidance on this issue for 
PostGres.  Anyone have any suggestions?

Thanks,
Tom

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [SQL] TEXT blob extraction in ecpg

2005-01-10 Thread Michael Fuhr
On Mon, Jan 10, 2005 at 01:02:00PM -0500, none none wrote:

> Does any one know how to properly extract a TEXT type blob (undefined char 
> length) in ecpg (Linux system)?

If you don't know how much memory to allocate for a column, you
could use a descriptor area and check RETURNED_OCTET_LENGTH.  See
the "Using SQL Descriptor Areas" section in the ECPG documentation.

-- 
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [SQL] Question about insert/update RULEs.

2005-01-10 Thread Ron Peterson
On Sun, Jan 09, 2005 at 06:45:54AM -0500, Dmitri Bichko wrote:

> CREATE TABLE "foo" (
>   "foo_id"serial PRIMARY KEY,
>   "type"  varchar NOT NULL DEFAULT 'base' CONSTRAINT types CHECK
> (type IN ('base', 'bar'))
>   "a" varchar NOT NULL,
>   "b" varchar DEFAULT 'some text',
> );
> 
> CREATE TABLE "foo_bar" (
>   "foo_id" integer PRIMARY KEY CONSTRAINT foo REFERENCES foo (foo_id) ON
> DELETE CASCADE ON UPDATE CASCADE DEFERABLE,
>   "c" varchar
> );
> 
> CREATE VIEW "bar" AS
> SELECT f.foo_id, f.a, f.b, b.c
> FROM foo f JOIN foo_bar b USING(foo_id);
> 
> CREATE RULE "bar_insert" AS ON INSERT TO "bar"
>   DO INSTEAD (
>   INSERT INTO "foo" (foo_id, type, a, b) VALUES
> (NEW.foo_id, 'bar', NEW.a, NEW.b);
>   INSERT INTO "foo_bar" (foo_id, c) VALUES (NEW.foo_id,
> NEW.c);
>   );
> 
> The problem is that for the sequence to do the right thing, I have to
> select nextval first in a separate query and then pass it explicitely to
> INSERT INTO "bar" (which C:DBI does anyway, but I'd like to do better).
> 
> If I were to do this:
>  foo insert: foo_id = COALESCE(NEW.foo_id, nextval('foo_foo_id_seq')),
>  foo_bar insert: foo_id = COALESCE(NEW.foo_id,
> currval('foo_foo_id_seq')),

I believe you may be trying to do something like the following:

CREATE RULE bar_insert AS
ON INSERT TO bar
DO INSTEAD
(
  INSERT INTO
foo ( food_id, type, a, b )
  VALUES
( nextval( 'foo_foo_id_seq' ), ... );

  INSERT INTO
foo_bar ( foo_id, c )
  VALUES
( currval( 'foo_foo_id_seq' ), ... );
);

(Which would mean there's no reason for view 'bar' to display foo_id)

Hmm, just noticed you defined foo.foo_id to be type 'serial', so you
could omit foo_id in the first INSERT.

> Will the currval() be guaranteed to be the same value that the nextval()
> got?  I am not quite sure what the "scope" of currval() is.

The value of currval will be predictable within the current session.
I.E., if another session increments the sequence, the value returned by
currval in the current session won't change.

Best.

-- 
Ron Peterson
Network & Systems Manager
Mount Holyoke College
http://www.mtholyoke.edu/~rpeterso


---(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