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
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 asked for additional use cases, which currently need direct
26 matches
Mail list logo
