Tom Lane wrote:
> "Roderick A. Anderson" <raanders@cyber-office.net> writes:
>> While and after doing a import ("\i file_dump") I notice one table had
>> two attributes with a type of "unknown".
>
> Is it a table, or a view? This is hardly unheard-of for views,
> consider
Table. The columns are to hold a credit card number and its expiration
date.
> regression=# create view v1 as select 'unmarked string' as c1;
> WARNING: column "c1" has type "unknown"
> DETAIL: Proceeding with relation creation anyway.
> CREATE VIEW
> regression=# \d v1
> View "public.v1"
> Column | Type | Modifiers
> --------+---------+-----------
> c1 | unknown |
> View definition:
> SELECT 'unmarked string' AS c1;
>
> It's possible but much less common to have such things in plain tables.
>
>> So the question is; is it possible to have a custom type in a cluster
>> that is accessible/usable in a database but isn't picked up by pg_dump?
>
> This has got nothing to do with missing types.
OK. I don't have access to the system the dump comes from. I assumed
:-) that there might be a type that did integrity checks or validated
the data during inserts or updates and the pg_dump just did an "Unknown"
for some reason.
It has been too long since I dealt with CC data but I seem to remember
there were some checks for number of digits, beginning digits,
expiration date, etc. (a quick check with Google confirms this.)
I was thinking they might have actually put that logic in the model
instead of the controller. Therefore it was a "missing" type
declaration issue.
Sorry for being vague. I know the application (which I'm pretty sure
has been modified) and the company that the dump came from but don't
feel comfortable sharing. I'll go look at the original database stuff
from the application to see if I can find anything that sheds some light
on this.
Thanks.
\\||/
Rod
--
