06.04.2013 1:24, Ann Harrison wrote:
>> DBKEY for views is a fake, it does not exist as a standalone physical
>> concept. So I ignore views in this thread, they're completely outside
>> the intended semantics of this proposal.
>
> Perhaps the implementation has changed, but formerly the db_key of
On Fri, Apr 5, 2013 at 12:59 PM, Dmitry Yemanov wrote:
>
> > But variable length for views?
>
> DBKEY for views is a fake, it does not exist as a standalone physical
> concept. So I ignore views in this thread, they're completely outside
> the intended semantics of this proposal.
>
> Perhaps the
2013/4/5 Ann Harrison :
> I think that's the intention of the standard, but like Dmitry, I have been
> unable to find a clear statement to that effect. If it matters to anybody,
> I've got a couple of friends who are serious standards addicts and I could
> ask for a reference there. The Red Datab
05.04.2013 13:07, Kjell Rilbe wrote:
> But variable length for views?
DBKEY for views is a fake, it does not exist as a standalone physical
concept. So I ignore views in this thread, they're completely outside
the intended semantics of this proposal.
Dmitry
-
05.04.2013 18:08, Ann Harrison wrote:
> I like the function approach.
Function is fine if it produces really human-readable form. Say,
SSS:P: where
SSS is pagespace, PP - page number and - record number. Plain BinToHex
worth nothing.
--
WBR, SD.
-
On Fri, Apr 5, 2013 at 11:34 AM, Doug Chamberlin
wrote:
>
>> I would implement it so that if a user does not have SELECT permission on
> a field that any mention of that field in a SELECT statement is an outright
> error for that user. Just as if the field did not exist.
>
> I think that's the int
> > Unfortunately, DBKEY has variable size and not always fit into int64.
>
> It has a fixed size and its recno part (leaving the relation id aside)
> always fits into int64.
>
> It's currently fixed at 8 bytes for simple tables and 8 bytes * number of
streams
for views. I like the function approa
>Bad idea, IMHO. I predict a lot of support request "I see in SHOW TABLE
> that
> field exists, but select throw me error that it doesn't". Error message must
> clearly state its
> reason: "not enough rights to read this field".
That could be addressed by adding "Permission" or "Accessible"
05.04.2013 17:34, Doug Chamberlin wrote:
> I would implement it so that if a user does not have SELECT permission on a
> field that any
> mention of that field in a SELECT statement is an outright error for that
> user. Just as if
> the field did not exist.
Bad idea, IMHO. I predict a lot of
On Fri, Apr 5, 2013 at 10:52 AM, Alexandre Benson Smith <
ibl...@thorsoftware.com.br> wrote:
> I don't think trowing an error is the best, the select could be
> performed but no value returned for that column. The engine should
> provide mechanisms to treat it as a whole like
>
> select * from MyT
Em 4/4/2013 22:53, Doug Chamberlin escreveu:
> So forget the previous discussion for a moment. Especially any parts
> about the best ways to implement replication and SELECT * problems.
>
> Without getting into the details of the use case, essentially the OP
> asked for a way to suppress the pres
Computed by columns and position function
-
Key: CORE-4074
URL: http://tracker.firebirdsql.org/browse/CORE-4074
Project: Firebird Core
Issue Type: Bug
Components: API / Client Library, Engine
05.02.2013 10:03, Dmitry Yemanov wrote:
> Not for user fields, but DBKEY is somewhat special.
I don't see anything special on it.
If you store it in "user field" will anything change in it? No.
Does it have standard textual representation which is different from
ordinary hex dump
as GUI
Den 2013-02-05 10:03 skrev Dmitry Yemanov såhär:
> 05.04.2013 12:14, Dimitry Sibiryakov wrote:
>> Unfortunately, DBKEY has variable size and not always fit into int64.
> It has a fixed size and its recno part (leaving the relation id aside)
> always fits into int64.
Er... But variable length for v
05.04.2013 12:27, Alex Peshkoff wrote:
> But if we forget about hiding something from people - is not it useful
> to change behavior of 'select *' in a case when some fields are not
> selectable?
I don't mind, it just won't solve the problem being discussed here.
Dmitry
--
05.04.2013 12:14, Dimitry Sibiryakov wrote:
> AFAIK, DBKEY has type CHAR(X) CHARACTER SET OCTETS. CORE-3039 is closed with
> resolution
> "won't fix". Obviously, there is no need for human readable form of such
> fields.
Not for user fields, but DBKEY is somewhat special.
> Unfortunately, DBKE
> I'd like to propose some ways to convert DBKEY into a human-readable
> form but still be able to quickly (without a full table scan) access the
> record via its human-readable DBKEY.
>
> Primarily, it could be used to report a unique id of the offending
> record in error messages allowing use
On 04/05/13 07:50, Dmitry Yemanov wrote:
> 05.04.2013 5:53, Doug Chamberlin wrote:
>
>> Seems to me the leading solution would be to extend SQL compliance for
>> permissions on fields to the SELECT statement such that users would not
>> be able to SELECT fields for which they did not have permissio
05.04.2013 8:04, Dmitry Yemanov wrote:
> So far I can think of two solutions:
>
> 1) Add two symmetric built-in functions: DBKEY_TO_CHAR and
> CHAR_TO_DBKEY. The former one would return the predefined hex-encoded
> textual representation of the DBKEY while the latter one would perform
> the opposit
> -Oprindelig meddelelse-
> Fra: Leyne, Sean [mailto:s...@broadviewsoftware.com]
> Sendt: 4. april 2013 17:59
> Til: For discussion among Firebird Developers
> Emne: Re: [Firebird-devel] RFC: non-expandable fields
>
>
>
> > So, the proposition is simple: add ability for engine to dist
05.04.2013 10:54, Mark Rotteveel wrote:
> Given the instability of DBKEY over multiple transactions, how useful is
> this?
The more useful the closer we're to the source of problem to be
investigated using that DBKEY ;-) No absolute guarantee of course and
users should be aware of that.
Dmitr
21 matches
Mail list logo
