Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The field pg_language.lanispl seems to have several different meanings:
> 1. This is a user-defined language.
> 2. This language may be dropped.
> 3. You may define a trigger using a function defined in this language (or
> in C or in internal).
[EMAIL PROTECTED] (Neil Conway) writes:
> I'd like to add the ability to use a sub-select in a CHECK constraint.
> Can someone elaborate on what changes would be needed to support
> this?
Define what you think should happen when the other rows referenced
by the subselect change.
On Sat, Jul 27, 2002 at 07:07:13PM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] (Neil Conway) writes:
> > I'd like to add the ability to use a sub-select in a CHECK constraint.
> > Can someone elaborate on what changes would be needed to support
> > this?
>
> Define what you think should happen whe
Tom Lane writes:
>
>
> "Robert E. Bruccoleri" <[EMAIL PROTECTED]> writes:
> > On SGI multiprocessor machines, I suspect that a spinlock
> > implementation of LWLockAcquire would give better performance than
> > using IPC semaphores. Is there any specific reason that a spinlock
> > could not be
The field pg_language.lanispl seems to have several different meanings:
1. This is a user-defined language.
2. This language may be dropped.
3. You may define a trigger using a function defined in this language (or
in C or in internal).
4. Functions defined in this language may be call
Tom Lane writes:
> What about requiring ownership of at least one of the types?
Yes, that would work.
There would be a somewhat bizzare consequence, though: User U1 creates
type T1, user U2 creates type T2. Then user U1 creates a cast from T1 to
T2. Now user U2 would be allowed to drop that
Zeugswetter Andreas SB SD writes:
> > What about requiring ownership of at least one
> > of the types?
>
> I was thinking that too, but, would it be possible to circumvent such
> a restriction with a "type in the middle" attack ?
> Create your own type and then
> 1. (auto)cast type1 to own type
I'd like to add the ability to use a sub-select in a CHECK constraint.
Can someone elaborate on what changes would be needed to support
this? From a (very) brief look at execMain.c, ExecEvalExpr() seems
to support subplans already, so I wouldn't *guess* it would be too
involved, but I'd appreciate
[EMAIL PROTECTED] (Neil Conway) writes:
> Good point -- but given that SQL99 specifically mentions that this
> functionality should be available (Feature 671, "Subqueries in
> CHECK constraints"), there must be some reasonable behavior
> adopted by another DBMS...
It's effectively equivalent to a
