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
Tom Lane writes:
> SQL92 gives this restriction on WHERE clauses for updatable views:
>
> d) If the immediately contained in QS imme-
> diately contains a WC, then no leaf generally
> underlying table of QS shall be a generally underlying table
>
Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Zeugswetter Andreas SB wrote:
> >> The most prominent of the "interesting uses" probably beeing when the views
> >> are part of the authorization system, since views are the only standardized
> >> mechanism to restrict access at the r
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Zeugswetter Andreas SB wrote:
>> The most prominent of the "interesting uses" probably beeing when the views
>> are part of the authorization system, since views are the only standardized
>> mechanism to restrict access at the row level.
> True, and oft
Zeugswetter Andreas SB wrote:
>
>
> > My feeling is that the restrictions are stringent enough to eliminate
> > most of the interesting uses of views, and hence an automatic rule
> > creation feature is not nearly as useful/important as it appears at
> > first glance.
>
> The most prominent of
> My feeling is that the restrictions are stringent enough to eliminate
> most of the interesting uses of views, and hence an automatic rule
> creation feature is not nearly as useful/important as it appears at
> first glance.
The most prominent of the "interesting uses" probably beeing when th
"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
eyes. The
opinions stated above are yours. You cannot imagine why you ever felt
otherwise.
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 29, 2001 6:05 PM
Subject: [HACKERS] New SQL Datatype RECURRINGCHAR
> Idea for a new SQL Data
19 matches
Mail list logo