Обсуждение: "Hidden" field for each column

Hi,

Is there any way that I can consistently (across all
tables) add a parameter defining "what" each column
"is"?  (sorry, crappy grammar and ill-formed question).

I want to be able to embed in the database parameters
that tell it how to interpret each column.  In other
words, while the TYPE for two columns might be
text/char/varchar/etc., the data that each contained
could have vastly different interpretations.

For example, it might be a surname.  Or, the name of
a city.  Or, the name of a handtool.  Or a street address.

I would like the support routines to be able to look at
these parameters and adjust queries and other activities
accordingly.  So, when matching a surname, it might
apply some heuristics built on metaphone.  Yet, when
matching a book's title, may try some simple substitutions
and permutations (e.g., stripping words like "The" from
the beginning of the title; or relaxing rules for
punctuation or capitalization).

Burying this information in the database itself will let
the applications be unconcerned with adding this level
of support at their level -- and afford all applications
a consistent set of capabilities.

On a similar, but different, note, are there any ways
to "hide" a value behind each datum?  I.e. to treat
each entry as a struct containing the actual data type
PLUS this "hidden" value?  Without explicitly creating
ADT's for each potential datatype?

(sorry, I realize both questions are off-the-wall and
I can undoubtedly come up with kludges to implement them
but I was hoping for something "slicker"... :>)

Thanks!
--don

Don Y <pgsql@DakotaCom.Net> writes:
> I want to be able to embed in the database parameters
> that tell it how to interpret each column.  In other
> words, while the TYPE for two columns might be
> text/char/varchar/etc., the data that each contained
> could have vastly different interpretations.

If I were you, I'd probably do that by creating a bunch of domains
and using the domains instead of plain text/etc as the column types.
See CREATE DOMAIN.

You could also commandeer the COMMENT ON COLUMN facility if you'd
rather have a text string associated with each column.

            regards, tom lane

You can specifiy a "comment" on each field....


"Don Y" <pgsql@DakotaCom.Net> wrote in message
news:443D3EF7.10205@DakotaCom.Net...
> Hi,
>
> Is there any way that I can consistently (across all
> tables) add a parameter defining "what" each column
> "is"?  (sorry, crappy grammar and ill-formed question).
>
> I want to be able to embed in the database parameters
> that tell it how to interpret each column.  In other
> words, while the TYPE for two columns might be
> text/char/varchar/etc., the data that each contained
> could have vastly different interpretations.
>
> For example, it might be a surname.  Or, the name of
> a city.  Or, the name of a handtool.  Or a street address.
>
> I would like the support routines to be able to look at
> these parameters and adjust queries and other activities
> accordingly.  So, when matching a surname, it might
> apply some heuristics built on metaphone.  Yet, when
> matching a book's title, may try some simple substitutions
> and permutations (e.g., stripping words like "The" from
> the beginning of the title; or relaxing rules for
> punctuation or capitalization).
>
> Burying this information in the database itself will let
> the applications be unconcerned with adding this level
> of support at their level -- and afford all applications
> a consistent set of capabilities.
>
> On a similar, but different, note, are there any ways
> to "hide" a value behind each datum?  I.e. to treat
> each entry as a struct containing the actual data type
> PLUS this "hidden" value?  Without explicitly creating
> ADT's for each potential datatype?
>
> (sorry, I realize both questions are off-the-wall and
> I can undoubtedly come up with kludges to implement them
> but I was hoping for something "slicker"... :>)
>
> Thanks!
> --don
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>