Hi Carlos,
> Anyway, I don't care about the syntax. Just make sure that removing
> the source will still be possible in future versions. It is a "false"
> security, but it works for most of the people.
+1 - one more reason why it is a useful thing to have:If you're a "good" coder,
you document t
Hi Claudio,
>> From: Frank Ingermann [mailto:fr...@fingerman.de]
>>
>> Still i think it's a no-go to just take the ability _away_ to
>> clear out those sources. It IS common practise.
(+1 for the COMMENTs!)
> The problem is that we lack equivalent commands for sources and debugging.
> Then if w
> -Original Message-
> From: Frank Ingermann [mailto:fr...@fingerman.de]
> Sent: Miércoles, 30 de Noviembre de 2011 19:32
>
> Still i think it's a no-go to just take the ability _away_ to
> clear out those sources. It IS common practise.
I don't see any reason to forbid it either. Let's
On 11/30/11 13:50, Adriano dos Santos Fernandes wrote:
> On 30/11/2011 03:53, Alex Peshkoff wrote:
>> On 11/30/11 02:42, Frank Ingermann wrote:
>>> DROP SOURCE OF [||*]
>>> or
>>> CHANGE OWNER OF [|*] TO
>> This approach looks much better than use of system package.
>>
>>
> I don't think bloat t
On 30/11/2011 03:53, Alex Peshkoff wrote:
> On 11/30/11 02:42, Frank Ingermann wrote:
>> DROP SOURCE OF [||*]
>> or
>> CHANGE OWNER OF [|*] TO
> This approach looks much better than use of system package.
>
>
I don't think bloat the language with non-standard syntax for
non-mainstream tasks is a
> On 11/30/11 02:42, Frank Ingermann wrote:
>> DROP SOURCE OF [||*]
>> or
>> CHANGE OWNER OF [|*] TO
>
> This approach looks much better than use of system package.
Or more "object type bound", e.g.:
ALTER TABLE ... CHANGE OWNER TO ...
ALTER VIEW ... CHANGE OWNER TO ...
etc..
ALTER PROCEDURE
Frank wrote:
> Using the API is one thing, but imho it should be possible to do all of
that
> from within a SQL script - like
>
> DROP SOURCE OF [||*] or CHANGE
> OWNER OF [|*] TO
I like this.
What about ?
Magnus
--
On 11/30/11 02:42, Frank Ingermann wrote:
> DROP SOURCE OF [||*]
> or
> CHANGE OWNER OF [|*] TO
This approach looks much better than use of system package.
--
All the data continuously generated in your IT infrastructu
Hi Sean / *,
Am 29.11.2011 22:47, schrieb Leyne, Sean:
> Again, though how would that be done in SQL?
right - the original question was: can direct modification
of system tables be completely disabled, and (if yes):
what alternatives would we need...to still be able to do
what we do nowadays _wit
On 29-11-2011 19:47, Leyne, Sean wrote:
> Adriano,
>
>> I thing something like:
>>
>> firebird.set_comment(, , )
>
> Seems fine to me. But how would that be done in SQL statement, without
> direct manipulation of the system tables?
>
>
BTW, "FIREBIRD" seems a not good name for that. Better re
Adriano,
> I thing something like:
>
> firebird.set_comment(, , )
Seems fine to me. But how would that be done in SQL statement, without direct
manipulation of the system tables?
> firebird.set_source(, , )
This would allow for a user to set the source to be any value (= "Hello
World"). {
On 29-11-2011 18:28, Claudio Valderrama C. wrote:
>> -Original Message-
>> From: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com]
>> Sent: Martes, 29 de Noviembre de 2011 6:41
>>>
>> I believe it's better to have a system package with functions
>> able to do
>> that, instead of
How about a command that actually shows the comments on an object
without having to read the system tables?
Security grants for creating and viewing the comments?
Right now you can use various tricks to grant and revoke rights on
system tables, giving various levels of security, but there is no
n
> -Original Message-
> From: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com]
> Sent: Martes, 29 de Noviembre de 2011 6:41
> >
> I believe it's better to have a system package with functions
> able to do
> that, instead of continue allowing these changes directly.
Yes, no more
14 matches
Mail list logo
