Dmitry,
> True, db_keys from aggregate views are problematic, but not for simple
> > joined views.
>
> Correct and it hasn't changed. I just meant that the view's DBKEY is not
> something separate, it simply a concatenation of the individual tables
> DBKEYs. You cannot select from a joined view us
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
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.
-
> > 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
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: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
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
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
On Fri, 05 Apr 2013 10:04:13 +0400, Dmitry Yemanov
wrote:
> All,
>
> 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.
Given the instability of DBKEY over multip
Hi,
Dne 5.4.2013 08:04, Dmitry Yemanov napsal(a):
> All,
>
> 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
14 matches
Mail list logo
