On 06.02.2015 19:58, Dmitry Yemanov wrote:
> At the first glance, one might think that all we need is to change
> stuff_exception() to append instead of overwriting. But it's not really
> so. Given how many times we may catch and re-throw within the call
> stack, I'd expect lots of duplicated ite
07.02.2015 11:27, Alex Peshkoff wrote:
> Completely removing tdbb_status_vector will break warnings delivery.
I would suggest to reconsider the existence of warnings at all.
--
WBR, SD.
--
Dive into the World of P
WhatbI have done on other database systems, and it has worked very well, is
allow authorized roles for a user to be assumed and dropped at anytime
during a connection. Access to an object is allowed if the access is
allowed in any of the active roles. There is also a mechanism to state
which roles
On 02/07/15 03:20, Geoff Worboys wrote:
> Simple? Well, I guess it is if I don't have any care about
> security. But context variables are not the way to do this
> sort of thing, load on demand from a secured table is a less
> open way of dealing with such private data.
In FB3 one also can rathe
On 02/07/15 13:31, Dimitry Sibiryakov wrote:
> 07.02.2015 11:27, Alex Peshkoff wrote:
>> Completely removing tdbb_status_vector will break warnings delivery.
> I would suggest to reconsider the existence of warnings at all.
>
They are present in SQL standard.
07.02.2015 13:13, Alex Peshkoff wrote:
> On 02/07/15 13:31, Dimitry Sibiryakov wrote:
>> I would suggest to reconsider the existence of warnings at all.
>
> They are present in SQL standard.
It doesn't make them useful in any meaning.
I started a couple of discussions on sql.ru and they
On 7-2-2015 13:24, Dimitry Sibiryakov wrote:
> 07.02.2015 13:13, Alex Peshkoff wrote:
>> On 02/07/15 13:31, Dimitry Sibiryakov wrote:
>>> I would suggest to reconsider the existence of warnings at all.
>>
>> They are present in SQL standard.
>
> It doesn't make them useful in any meaning.
07.02.2015 13:47, Mark Rotteveel wrote:
> Yes it does: consider connecting with the wrong dialect (eg 1 to 3 or 3
> to 1), I want to receive a warning when that happens.
What will you do then? I guess that you will disconnect and connect with a
right
dialect. Wouldn't it be better to get it a
07.02.2015 13:47, Mark Rotteveel wrote:
> consider connecting with the wrong dialect (eg 1 to 3 or 3 to 1)
BTW, dialect is not an connection's attribute.
--
WBR, SD.
--
Dive into the World of Parallel Programming.
On 02/07/15 15:54, Dimitry Sibiryakov wrote:
> 07.02.2015 13:47, Mark Rotteveel wrote:
>> consider connecting with the wrong dialect (eg 1 to 3 or 3 to 1)
> BTW, dialect is not an connection's attribute.
>
It is connection attribute: isc_dpb_sql_dialect.
It affects how role is processed during
07.02.2015 14:00, Alex Peshkoff wrote:
> It is connection attribute: isc_dpb_sql_dialect.
> It affects how role is processed during connection.
IIRC, it also affect dialect of database during isc_create_database().
That's all.
Mark, I guess, rather referred to queries' dialect...
--
WB
Hi,
what security risk do you see with context vars?
Context vars are stored on server side - what i am missing here?
This so secure as secure is sending password at conection start time ;-)
I you secure transmision what problem?
regards,
Karol Bieniaszewski
-Oryginalna wiadomość-
From:
07.02.2015 13:27, Alex Peshkoff wrote:
>
> I do not see too big trouble with full checks of string args. But what
> about keeping legacy dup check present in ERR_post()? Taking into an
> account that string once made permanent will remain the same per thread
> suppose it will be enough for most cas
On 7-2-2015 13:52, Dimitry Sibiryakov wrote:
> 07.02.2015 13:47, Mark Rotteveel wrote:
>> Yes it does: consider connecting with the wrong dialect (eg 1 to 3 or 3
>> to 1), I want to receive a warning when that happens.
>
> What will you do then? I guess that you will disconnect and connect with
On 7-2-2015 13:54, Dimitry Sibiryakov wrote:
> 07.02.2015 13:47, Mark Rotteveel wrote:
>> consider connecting with the wrong dialect (eg 1 to 3 or 3 to 1)
>
> BTW, dialect is not an connection's attribute.
>
Yes it is.
--
Mark Rotteveel
--
07.02.2015 13:27, Alex Peshkoff wrote:
>
> I.e. if we decide to go this way we should do this with all catch blocks
> which is a change not differing much in volume of changes from changing
> tdbb_status_vector to something capable to store unlimited length vectors.
True. But I don't suggest to do
On 02/07/15 16:32, liviusliv...@poczta.onet.pl wrote:
> Hi,
>
> what security risk do you see with context vars?
> Context vars are stored on server side - what i am missing here?
> This so secure as secure is sending password at conection start time ;-)
Password is NOT sent at connection time whe
On 02/07/15 16:41, Dmitry Yemanov wrote:
> 07.02.2015 13:27, Alex Peshkoff wrote:
>> I do not see too big trouble with full checks of string args. But what
>> about keeping legacy dup check present in ERR_post()? Taking into an
>> account that string once made permanent will remain the same per thr
On 02/07/15 16:43, Dmitry Yemanov wrote:
> 07.02.2015 13:27, Alex Peshkoff wrote:
>> I.e. if we decide to go this way we should do this with all catch blocks
>> which is a change not differing much in volume of changes from changing
>> tdbb_status_vector to something capable to store unlimited leng
07.02.2015 14:40, Mark Rotteveel wrote:
> Warnings are an existing feature in Firebird and I see no reason why
> they should be removed.
Because they make API inconsistent and complicate application development.
Modern programming ideology is that function must returning only one result
and
Accessing DB in invalid manner when links (hard or symbolic) are used for it
Key: CORE-4685
URL: http://tracker.firebirdsql.org/browse/CORE-4685
Project: Firebird Core
On 7-2-2015 15:54, Dimitry Sibiryakov wrote:
> 07.02.2015 14:40, Mark Rotteveel wrote:
>> Warnings are an existing feature in Firebird and I see no reason why
>> they should be removed.
>
> Because they make API inconsistent and complicate application development.
> Modern programming ideol
Truncation during a cast should raise a warning, not an exception
-
Key: CORE-4686
URL: http://tracker.firebirdsql.org/browse/CORE-4686
Project: Firebird Core
Issue Type: Bug
Alex Peshkoff wrote:
> On 02/07/15 03:20, Geoff Worboys wrote:
>> Simple? Well, I guess it is if I don't have any care about
>> security. But context variables are not the way to do this
>> sort of thing, load on demand from a secured table is a less
>> open way of dealing with such private data.
liviusliv...@poczta.onet.pl wrote:
> Hi,
> what security risk do you see with context vars?
> Context vars are stored on server side - what i am missing
> here?
> This so secure as secure is sending password at conection
> start time ;-)
> I you secure transmision what problem?
> regards,
> Karol
25 matches
Mail list logo
