"Steve Wolfe" <[EMAIL PROTECTED]> writes:
> After this is all set up, if anyone would like, I may type up an
> explanation of how things were done as well as costs, for those going
> through the same sort of growing pains. It's certainly been a lot of work
> for us to hammer out all of the detail
> After this is all set up, if anyone would like, I may type up an
> explanation of how things were done as well as costs, for those going
> through the same sort of growing pains. It's certainly been a lot of
> work for us to hammer out all of the details, hopefully that would
> help someone e
> >How should a RESTRICT or ON
> >DELETE CASCADE work in that scenario?
>
> Perhaps as Check constraints on all tables in the view...for the most part
> I would not expect complex views to be used in this way, but since this is
> what the user would have to do anyway, why not do it for t
At 17:56 30/06/00 +0200, Jan Wieck wrote:
>
>For gods sake they don't have. And I'm uncertain that it
>should ever work.
Sorry...I'm the one to blame for the suggestion. My only defense is it was
late, and I was misled by the parser...never the less...
>How should a RESTRICT o
"Mitch Vincent" <[EMAIL PROTECTED]> writes:
> I have this code...
> tupdesc = rel->rd_att; /* what the tuple looks like (?) */
> app_id_colnum = SPI_fnumber(tupdesc, app_id_fieldname);
> if (app_id_colnum == SPI_ERROR_NOATTRIBUTE)
>elog(ERROR, "app_id_colnum - SPI_ERROR_NOATTRIBUTE err
> Since most RAID servers can't even flood a 100 mbit connection, you're
more
> than safe with that much bandwidth if most of your traffic is going to be
> database related. You might want to factor in all the other network
> traffic that will be going over those lines though. For instance, if t
