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
On 12/15/13 05:27, Adriano dos Santos Fernandes wrote:
> Hi!
>
> Syntax for attributes for users (CORE-4290) is not good IMO.
>
> Current:
>
> create user x password 'y' [set] a [to] 'a', b [to] 'b';
>
> alter user x [set] a [to] 'a', b [to] 'b';
>
> alter user x drop a, b;
>
> In think syntax belo
Hi!
Syntax for attributes for users (CORE-4290) is not good IMO.
Current:
create user x password 'y' [set] a [to] 'a', b [to] 'b';
alter user x [set] a [to] 'a', b [to] 'b';
alter user x drop a, b;
In think syntax below is better:
create user x password 'y' set a = 'a', b = 'b';
alter user
26 matches
Mail list logo
