David Bennett wrote:
> Alex,
>
> I think I fully understand your position. Let me put wrap up our
> conversation so far.
> [lots of arguments for recurringchar]
All I've seen up to now is that you continue to mix up
simplification on the user side with data and content control
2001 4:49 PM
To: Rod Taylor
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [HACKERS] New SQL Datatype RECURRINGCHAR
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> This is rather like MySQL's enum.
Yes. If we were going to do anything like this, I'd vote f
Alex,
I think I fully understand your position. Let me put wrap up our
conversation so far.
Given the application requirements:
1) contacts have a type.
2) new types must be added on the fly as needed.
3) types names rarely change.
4) the number of contacts should scale to support m
> various disagreements and "quotes"...
I agree that you disagree :)
RECURRINGCHAR does not break normal form. It simply optimizes the storage
of reference values (recurring keys). This allows for the use of 'long
words' as reference values with a great deal of system storage savings and
>> It's apparent that there is a lot of duplicate space used in the storage
>> of this information. The idea is if order.status was stored as a
>> RECURRINGCHAR
>> then the only data stored for the row would be a reference to the value
of
>> the column. The actual values would be stored in a sepa
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Anyway, the point is that some of the simple views should be straight
> forward to reversing automatically if someone has the will and the
> time it can be done. A while back a list of 'views which cannot be
> reversed' was created and included things su
> > > This would be a potential feature of being able to insert into
> views
> > > in general. Reversing the CREATE VIEW statement to accept
> inserts,
> > > deletes and updates.
> > Definitely not a 'potential' feature, but a existing and
documented
> one.
> > Read up on rules, especially 'ON IN
> > This would be a potential feature of being able to insert into
views
> > in general. Reversing the CREATE VIEW statement to accept
inserts,
> > deletes and updates.
> Definitely not a 'potential' feature, but a existing and documented
one.
> Read up on rules, especially 'ON INSERT DO INSTEAD'
On Sat, 7 Jul 2001, Rod Taylor wrote:
> This would be a potential feature of being able to insert into views
> in general. Reversing the CREATE VIEW statement to accept inserts,
> deletes and updates.
Definitely not a 'potential' feature, but a existing and documented one.
Read up on rules, esp
-
From: "Alex Pilosov" <[EMAIL PROTECTED]>
To: "David Bennett" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, July 07, 2001 9:24 PM
Subject: RE: [HACKERS] New SQL Datatype RECURRINGCHAR
> On Sat, 7 Jul 2001, David Bennett wrote:
On Sat, 7 Jul 2001, David Bennett wrote:
> -
> In a nutshell you are recommending:
> -
>
> create table contact_type (
> codeint2,
> typechar(16),
> PRIMARY KEY ( code )
> );
>
> create table contact (
> numberserial,
> name char(32),
>
On Fri, 6 Jul 2001, David Bennett wrote:
> In either model you would:
>
> update master_table set status='OPEN_PENDING_SOMETHING' where status='OPEN'
>
> This would not change, in fact, even in a normalized design you
> wouldn't change the lookup table (parent) key. Perhaps you are
> mi
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> This is rather like MySQL's enum.
Yes. If we were going to do anything like this, I'd vote for stealing
the "enum" API, lock stock and barrel --- might as well be compatible.
regards, tom lane
---(end of
This is rather like MySQL's enum. I still opt for the join, and if
you like make a view for those who don't want to know the data
structure.
--
Rod Taylor
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinio
14 matches
Mail list logo
