Re: postgres adapater problem with create_table :id => false

JeffV
Wed, 21 Oct 2009 16:07:22 -0000

The downside is pretty large: it doesn''t work if I define a composite
PK. If you read my posting above you''ll see that I get a Postgres
adapter error on the RETURNING statement. That and the fact that this
is a logging table (in a legacy DB) with no PK(s). The columns are:
doc_id (not unique), user_id (not unique), date viewed (not unique),
and the combination is not unique.  That''s it! No PK. It''s not
my
insistence, but rather the nature of a logging table. A row in this
table is never updated, just INSERTs and SELECTs. I cannot add a
row_id column to this table as that would break many COBOL programs.
So that is life in the real world. By claiming the table has a single
PK via "set_primary_keys" (note it''s plural) it works.

Jeff

On Oct 21, 12:50 am, Marnen Laibow-Koser <rails-mailing-l...@andreas-
s.net> wrote:
> JeffV wrote:
> > doc_id is not a PK. An accurate model of the table would be:
> > set_primary_key nil
>
> Again: determine a suitable unique index (potentially composite, say,
> doc_id and something else) and declare that as your primary key in the
> DB.  This will have many advantages and virtually no downside AFAIK.
>
> > But the PG postgres adapter is unhappy with that because it''s
> > generating something like:
> >   INSERT into the_table VALUES (val1, val2...) RETURNING pk
> > when pk is nil the postgres adapter is unhappy.
> > For some reason the composite_primary_keys plugin fixes the problem
> > (as only a single PK is specified).
> > To me the problem is the PG adapter. I don''t know why it uses
> > RETURNING in its INSERT statement.
>
> No, the problem is in your insistence that you don''t want a PK.
 Really,
> any unique index will do the trick.  Stop fighting Rails and good DB
> design and declare one. :)
>
>
>
> > Jeff
>
> Best,
> --
> Marnen Laibow-Koserhttp://www.marnen.org
> mar...-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
> --
> Posted viahttp://www.ruby-forum.com/.