16.12.2013 22:01, Mark Rotteveel wrote:
> The Firebird 3 scrollable cursor hasn't been documented in the
> releasenotes. Is this an omission, or isn't it ready yet?
So far scrollable cursors are available in PSQL only. In DSQL, they're
surfaced in the new API but not implemented yet. This is why
The Firebird 3 scrollable cursor hasn't been documented in the
releasenotes. Is this an omission, or isn't it ready yet?
Mark
--
Mark Rotteveel
--
Rapidly troubleshoot problems before they affect your business. Most IT
Den 2013-12-16 12:40 skrev Dimitry Sibiryakov såhär:
> 16.12.2013 12:34, Kjell Rilbe wrote:
>> When you want to introduce a new fixed
>> attribute, X users will complain about clashes with their already-in-use
>> user defined attributes.
> In this case you suggest to do something like this: "al
Den 2013-12-16 12:28 skrev Mark Rotteveel såhär:
> On Mon, 16 Dec 2013 12:09:07 +0100, Kjell Rilbe
> wrote:
>> My thought exactly. I also wonder, if the general rule is to have
>> "...item valuetoset..." as opposed to "...item = valuetoset...", why
>> would you suddenly switch to "=" for user att
16.12.2013 12:34, Kjell Rilbe wrote:
> When you want to introduce a new fixed
> attribute, X users will complain about clashes with their already-in-use
> user defined attributes.
In this case you suggest to do something like this: "alter user x set
new_attr 'yy'
attributes (new_attr = 'zz')"
On 12/16/13 15:28, Mark Rotteveel wrote:
> I like this, but a problem with this is: what is the behavior if an
> existing attribute for the user isn't specified in an ALTER USER ..
> ATTRIBUTES(...)? Will that delete the attribute, or leave it untouched?
Certainly it will remain untouched.
> Wit
16.12.2013 12:32, Mark Rotteveel wrote:
> A user needs to have a password, it does not need to have attribute (or
> maybe: extended properties is a better name).
So what? Anything prevent FB from complaining for missed required attributes
in list?..
--
WBR, SD.
--
Den 2013-12-16 12:28 skrev Dimitry Sibiryakov såhär:
> 16.12.2013 12:18, Alex Peshkoff wrote:
>> On 12/16/13 15:14, Dimitry Sibiryakov wrote:
>>> Why one is needed? You can tell whether it is fixed or optional
>>> property by name, can't
>>> you?..
>>>
>> To make SQL operator human-readable.
On Mon, 16 Dec 2013 12:28:36 +0100, Dimitry Sibiryakov
wrote:
> 16.12.2013 12:18, Alex Peshkoff wrote:
>> On 12/16/13 15:14, Dimitry Sibiryakov wrote:
>>> Why one is needed? You can tell whether it is fixed or optional
>>> property by name, can't
>>> you?..
>>>
>> To make SQL operator hu
16.12.2013 12:18, Alex Peshkoff wrote:
> On 12/16/13 15:14, Dimitry Sibiryakov wrote:
>> Why one is needed? You can tell whether it is fixed or optional
>> property by name, can't
>> you?..
>>
> To make SQL operator human-readable. And must say I like this suggestion
>
> create user x passwor
On Mon, 16 Dec 2013 12:09:07 +0100, Kjell Rilbe
wrote:
> Den 2013-12-16 11:50 skrev Dimitry Sibiryakov såhär:
>> 16.12.2013 8:08, Alex Peshkoff wrote:
>>> And what do you think about a case when (I use old syntax for an
>>> example):
>>>
>>> alter user x [set] password 'y' [set] a [to] 'a', b [to]
Alex Peshkoff писал(а) в своём письме Mon, 16 Dec 2013
15:07:13 +0400:
> On 12/16/13 14:58, Simonov Denis wrote:
>> Dmitry Yemanov писал(а) в своём письме Mon, 16 Dec
>> 2013 14:48:12 +0400:
>>
>>> 16.12.2013 14:38, Simonov Denis wrote:
> Will the new name-value pairs also be retrievable f
On 12/16/13 15:09, Kjell Rilbe wrote:
> words, a syntax like this would seem a bit more robust:
>
> create user x password 'y' attributes (a = 'a', b = 'b');
> alter user x set password 'yy' attributes (a = 'aa', b = 'bb');
OK except (on my mind) word "attributes"
> I assume attribute identifier
On 12/16/13 15:14, Dimitry Sibiryakov wrote:
> 16.12.2013 12:08, Alex Peshkoff wrote:
>> On 12/16/13 14:50, Dimitry Sibiryakov wrote:
IMHO, for syntax consistency "set" should be placed before all
changing parameters.
I.e. if password identifies user record to be changed, "set"
On 16/12/2013 09:14, Dimitry Sibiryakov wrote:
>Why one is needed? You can tell whether it is fixed or optional property
> by name, can't
> you?..
>
Please, no. They are completely different things. One is used/required
internally. The others are misc. user data.
Adriano
-
16.12.2013 12:08, Alex Peshkoff wrote:
> On 12/16/13 14:50, Dimitry Sibiryakov wrote:
>> > IMHO, for syntax consistency "set" should be placed before all
>> > changing parameters.
>> >I.e. if password identifies user record to be changed, "set" after it is
>> >ok, but if
>> >password is a sub
Den 2013-12-16 11:50 skrev Dimitry Sibiryakov såhär:
> 16.12.2013 8:08, Alex Peshkoff wrote:
>> And what do you think about a case when (I use old syntax for an example):
>>
>> alter user x [set] password 'y' [set] a [to] 'a', b [to] 'b';
>>
>> Where should that set be placed? I prefer to:
>>
>> a
On 12/16/13 14:50, Dimitry Sibiryakov wrote:
> 16.12.2013 8:08, Alex Peshkoff wrote:
>> And what do you think about a case when (I use old syntax for an example):
>>
>> alter user x [set] password 'y' [set] a [to] 'a', b [to] 'b';
>>
>> Where should that set be placed? I prefer to:
>>
>> alter user
On 12/16/13 14:58, Simonov Denis wrote:
> Dmitry Yemanov писал(а) в своём письме Mon, 16 Dec
> 2013 14:48:12 +0400:
>
>> 16.12.2013 14:38, Simonov Denis wrote:
Will the new name-value pairs also be retrievable from sec$users? And
if
yes, how ? Text blob with all pairs?
>>> It was ni
Dmitry Yemanov писал(а) в своём письме Mon, 16 Dec
2013 14:48:12 +0400:
> 16.12.2013 14:38, Simonov Denis wrote:
>>
>>> Will the new name-value pairs also be retrievable from sec$users? And
>>> if
>>> yes, how ? Text blob with all pairs?
>>
>> It was nice to have some system stored procedure
16.12.2013 8:08, Alex Peshkoff wrote:
> And what do you think about a case when (I use old syntax for an example):
>
> alter user x [set] password 'y' [set] a [to] 'a', b [to] 'b';
>
> Where should that set be placed? I prefer to:
>
> alter user x password 'y' set a = 'a', b = 'b';
IMHO, for sy
16.12.2013 14:38, Simonov Denis wrote:
>
>> Will the new name-value pairs also be retrievable from sec$users? And if
>> yes, how ? Text blob with all pairs?
>
> It was nice to have some system stored procedure parses BLOB and returns a
> set of keys and values
Wouldn't a table e.g. SEC$USER_ATTRIB
> Will the new name-value pairs also be retrievable from sec$users?
Yes, certainly.
> And if
> yes, how ? Text blob with all pairs?
>
Yes.
>
> It was nice to have some system stored procedure parses BLOB and
> returns a
> set of keys and values
Certainly BLOB with pairs name=value is a compr
Robbert-Jan писал(а) в своём письме Mon, 16
Dec 2013 14:16:10 +0400:
>> On 16/12/2013 05:08, Alex Peshkoff wrote:
>>> I prefer to:
>>>
>>> alter user x password 'y' set a = 'a', b = 'b';
>>>
>>>
>> Me too.
>> Adriano
>
> And me too.
>
> Will the new name-value pairs also be retrievable from sec
>On 16/12/2013 05:08, Alex Peshkoff wrote:
>> I prefer to:
>>
>> alter user x password 'y' set a = 'a', b = 'b';
>>
>>
>Me too.
>Adriano
And me too.
Will the new name-value pairs also be retrievable from sec$users? And if
yes, how ? Text blob with all pairs?
Kind regards,
Robert
- NL
---
On 16/12/2013 05:08, Alex Peshkoff wrote:
> I prefer to:
>
> alter user x password 'y' set a = 'a', b = 'b';
>
>
Me too.
Adriano
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations
26 matches
Mail list logo
