Check out the Class::DBI docs under the description for 'has_a' and you will see the following:

*NOTE* You should not attempt to make your primary key column inflate using has_a() as bad things will happen. If you have two tables which share a primary key, consider using might_have() instead.

No reason is given why it's a bad thing, but I would trust them on it... Perhaps a read of the code will shed some light as to why this is bad, but I haven't the time. Regardless, this shouldn't segfault... segfaults are always a sign of a bug and if you have the time, you should try and trace it down and submit a bug report. I'd grab the latest perl and test that first though before spending a lot of time on it.

- Cees

There was no indication in the sample code that "employee" was a primary key in this table. I assumed it was some sort of tree structure, which should work just fine with has_a().

That is not how I read it...

Foo::Employee->has_a(employee => q{Foo::Employee});
[download]

That code shows that a recursive has_a is happening here linking Foo::Employee to itself. That on it's own should work, and I have used it successfully myself. But what about the following statement?

The idea was that if someone grabs the primary key of a row, return the object, not the integer PK.

That line implies to me that they are doing this with the primary key of the table. At least that's how I read it.

I'll admit that the fact that they are linking this to 'employee' makes it look suspect, but they specifically state they are dealing with a primary key... I guess a clarification by water would solve this confusion.

I do agree with your other comment that the segfault is not in Class::DBI. It could be an obscure perl bug, but more than likely it is the DBD driver for the database (either improperly installed, or buggy).

- Cees