AP> Well, this depends upon where the crypt key is stored. It's
AP> possible to(...)
Sure, the key "is the key" :)
AP> Unfortunately, that does not work for remote access. Even if we use a
AP> kind of safe, encrypted channel to talk to server and pass they key to
AP> it, how can we avoid installi
On 11/30/11 23:37, Carlos H. Cantu wrote:
> AdSF> If anyone write it and distribute it, it's easy for anyone. And it's not
> AdSF> difficult to write it.
>
> Maybe it is not difficult for core developers, but I don't think any of
> you will spend time with such thing, uh?
>
>>> Things will get bet
Hi Helen e.a.,
Am 30.11.2011 19:32, schrieb Helen Borrie:
>>>On 11/30/11 02:42, Frank Ingermann wrote:
DROP SOURCE OF [||*]
or
CHANGE OWNER OF [|*] TO
>> I don't think bloat the language with non-standard syntax for
>> non-mainstream tasks is a good thing.
@Adriano: i don't li
AdSF> If anyone write it and distribute it, it's easy for anyone. And it's not
AdSF> difficult to write it.
Maybe it is not difficult for core developers, but I don't think any of
you will spend time with such thing, uh?
>> Things will get better when crypto plugins and local users becomes a
>> r
At 10:50 PM 30/11/2011, 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
On 30/11/2011 16:05, Carlos H. Cantu wrote:
> AdSF> With BLR + debug_info it's very possible (and easy) to reconstruct
> AdSF> sources. And better, you don't even need to read the sources in the
> AdSF> original format style, but in the style you you want it!
>
> Probably not,
So as I suppose.
AdSF> With BLR + debug_info it's very possible (and easy) to reconstruct
AdSF> sources. And better, you don't even need to read the sources in the
AdSF> original format style, but in the style you you want it!
Probably not, but what you call "easy" probably is not true for 99% of
the standard FB
On 30/11/2011 14:52, Björn Reimer wrote:
> The discussion about removing sources or not makes little sense for
> me. It is possible with fb 2.5 and prior and should be possible in
> future versions as this feature is used. If you don't like it don't
> use it.
I wonder if these people who is re
> 30.11.2011 12:08, Thomas Steinmaurer wrote:
>> Or more "object type bound", e.g.:
>> ALTER TABLE ... CHANGE OWNER TO ...
>> ALTER VIEW ... CHANGE OWNER TO ...
> +1, although I'd prefer SET instead of CHANGE. And I believe that CREATE
> OR ALTER should miss this clause.
+1 That sounds very f
30.11.2011 12:27, Carlos H. Cantu wrote:
> AP>DROP SOURCE OF [||*]
>
> +1
May I suggest to borrow a term from Oracle and add clause "WRAPPED" to
"CREATE" or "ALTER"?
I.e "create wrapped procedure as ..." or "create procedure aaa wrapped
as ...".
It would make migration a bit easier
30.11.2011 12:17, Alex Peshkoff wrote:
> BLR remains.
Weren't you going to get rid of it someday?..
> Btw, I also do not like practice of dropping the sources. People use it
> as a kind of protection for the database. This protection is not efficient.
> But if users need that feature I can bet
DS>I agree with changing owner, but dropping the sources is a way to
nowhere. Firebird
DS> requires sources to recompile invalid objects.
Hiding procedure and triggers source is an approach widely used in
Brazil, as a way to "minimize" the chances of their logic being stolen
by anyone (I gues
On 11/30/11 14:39, Dimitry Sibiryakov wrote:
> 30.11.2011 9:08, Thomas Steinmaurer wrote:
>> Or more "object type bound", e.g.:
>>
>> ALTER TABLE ... CHANGE OWNER TO ...
>> ALTER VIEW ... CHANGE OWNER TO ...
>>
>> etc..
>>
>> ALTER PROCEDURE ... DROP SOURCE;
>>
>>
>> I have no idea if the SQL stan
30.11.2011 9:08, Thomas Steinmaurer wrote:
> Or more "object type bound", e.g.:
>
> ALTER TABLE ... CHANGE OWNER TO ...
> ALTER VIEW ... CHANGE OWNER TO ...
>
> etc..
>
> ALTER PROCEDURE ... DROP SOURCE;
>
>
> I have no idea if the SQL standard suggests here something.
I agree with changing own
30.11.2011 12:08, Thomas Steinmaurer wrote:
> Or more "object type bound", e.g.:
>
> ALTER TABLE ... CHANGE OWNER TO ...
> ALTER VIEW ... CHANGE OWNER TO ...
+1, although I'd prefer SET instead of CHANGE. And I believe that CREATE
OR ALTER should miss this clause.
Dmitry
-
On 29/11/2011 06:01, Dmitry Yemanov wrote:
> 28.11.2011 23:51, Helen Borrie wrote:
>
>> Here's another one: the COMMENT syntax for loading varchar text into
>> RDB$DESCRIPTION.
> Frank has shown a somewhat similar one: it's a more or less common
> practice to empty/nullify the RDB$***_SOURCE colu
29.11.2011 10:16, Mark Rotteveel wrote:
> Why shouldn't it be readable? It is very useful to retrieve and show
> metadata and regenerate DDL with a admin tool like flamerobin, or Eclipse
> Data Tools Platform.
They should be readable for owner and sysdba only.
--
SY, SD.
-
On Tue, 29 Nov 2011 10:04:58 +0100, Dimitry Sibiryakov
wrote:
> 29.11.2011 9:01, Dmitry Yemanov wrote:
>> Frank has shown a somewhat similar one: it's a more or less common
>> practice to empty/nullify the RDB$***_SOURCE columns.
>>
>> So perhaps, unless some good alternative can be offered, we co
29.11.2011 9:01, Dmitry Yemanov wrote:
> Frank has shown a somewhat similar one: it's a more or less common
> practice to empty/nullify the RDB$***_SOURCE columns.
>
> So perhaps, unless some good alternative can be offered, we could still
> allow modifications of particular columns that are known
At 08:40 PM 29/11/2011, Alex Peshkoff wrote:
>I'd better think about an ability to use BLOB in COMMENT. On the other
>hand, is it really required to have comments >32765/3 characters? This
>looks sooner not like a comment, but an average size presentation :)
Well it could be. Are we going to di
28.11.2011 23:51, Helen Borrie wrote:
> Here's another one: the COMMENT syntax for loading varchar text into
> RDB$DESCRIPTION.
Frank has shown a somewhat similar one: it's a more or less common
practice to empty/nullify the RDB$***_SOURCE columns.
So perhaps, unless some good alternative can
On 11/28/11 23:51, Helen Borrie wrote:
> At 02:03 AM 29/11/2011, Thomas Steinmaurer wrote:
>> Hello,
>>
>> Dmitry presented at the conference some things (AFAIK e.g. changing NULL
>> to NOT NULL and vice versa) in Firebird 3, which replaces the need for
>> directly updating the system tables, as
At 02:03 AM 29/11/2011, Thomas Steinmaurer wrote:
>Hello,
>
>Dmitry presented at the conference some things (AFAIK e.g. changing NULL
>to NOT NULL and vice versa) in Firebird 3, which replaces the need for
>directly updating the system tables, as this might be disallowed in FB 3
>anyway. He aske
On 28/11/2011 11:03, Thomas Steinmaurer wrote:
>
> - Changing the owner of database objects, which hold the owner
> information and everything additional needed for the conversion (e.g.
> SQL privileges etc ...)
>
>
This doesn't appear to be a daily task that requires special support
from the engi
On 11/28/11 17:03, Thomas Steinmaurer wrote:
> - Support for the inserting SYSDBA role trick, although I'm not sure if
> this is still important due to the new authentication plugin mechanism
This will become not needed not due to authentication plugins, but due
to mapping server logins (names w
25 matches
Mail list logo
