From: | Don Y <pgsql(at)DakotaCom(dot)Net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | "Hidden" field for each column |
Date: | 2006-04-12 17:55:03 |
Message-ID: | 443D3EF7.10205@DakotaCom.Net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Ted Byers | 2006-04-12 18:10:50 | Re: Hardware related question: 3ware 9500S |
Previous Message | Renato Cramer | 2006-04-12 17:49:46 | Off-Topic: DBMS Market Research |