There are a lot of ways we may store and transmit
anonymized ProdBase extracts. Some require only brief mention:
- XML. Very readable but kind of passe, and bloated. The bang
for us is small and the buck (processing overhead, bloat) too
high.
- JSON. Favored nowadays; created as a way to reduce XML's
bloat. It does, but only by about 50%. Still too bloated for
our use.
- EDI and other proprietary, obscure, and or "technical"
formats. Too much work and complexity; too-low bang for
too-high buck.
Possible/candidate storage and transmission format we may use
for anonymized ProdBase extracts:
- Key-value pairs
- Delimited flat files without header records
- Delimited flat files with header records
- Positionally formatted flat files, no header records
- Hybrid; positionally formatted followed by key-value
- Encoded single values
Advantages, disadvantages, and storage considerations of each of
these, I present below for discussion and consideration.
Key-value pairs
Currently one of the (leading) options for formatting an
anonymized ProdBase extract looks like this (lines truncated
here for display):
0000008F91D0401CAF5BC063F29310C02E40D89F|1270-11|1271-08X|1274-08O|1275-03O|1280-10|1281-02H|4151-44|4152-2
000002A365739E99657CD84AB646637A9E5B66C9|1270-36|1271-20S|1274-07C|1275-04C|1280-45|1281-10L|4151-70|4152-1
000002F7994DF919B73F4ACFB0AF659CD5C0A3E7|1270-20|1271-07X|1275-03O|1280-26|1281-06M|2507-00|2531-00
Advantages:
- No header record needed as long as all parties recognize
that the left column is an AshID. For humans that's easy - the
AshID is the left column, it looks different fromn all the
rest, it's the only column that doesn't contain a dash. These
are probably distinction enough to "set it off" - humans can
read this.
- Key-value pairs make the format self-documenting.
- Key-value pairs mean that new keys may be added at any time
- No recoding of export or import processes needed
- Downstream processes, though, may need recoding and/or
reconfiguration, to make use of the new data.
Disadvantages:
- This hybrid format will never be maximally nice to ingest
with automated tools. It's almost key-value pairs throughout,
but not quite; the first field has no key. Therefore a
"programming trick" will be needed prior to ingestion, if
automated parsing tools that expect key-value pairs are to be
used. Such "tricks" may or may not be available in all input
processing routines, packages, and/or languages. This extra
complexity can cause extra development effort, require more
moving parts, and/or slow processing in production.
- Possibility of duplication
- There is nothing within the file structure itself that
prevents something like this:
000002F7994DF919B73F4ACFB0AF659CD5C0A3E7|1270-20|1271-07X|1270-3O
Bloat:
- At a glance at sample data, about 65% bloat:
- Other than the AshID, every field consists of 1 to 3
characters of information, but 6 additional characters are
required for the encoding. Like so:
- Field: |1270-11
- Information content: 11
- Formatting and metadata: |1270-
- Average content, 2 characters. Average formatting and
metadata, 6 characters. This yields the 300% bloat.
- Upon analysis of sample data, 81% bloat:
- 72,651 bytes of values (50,760 total values)
- 381,091 bytes total of all value strings
- This yields the 81% bloat
Delimited flat-file records without headers
Another option, apparently currently possible/available (the
data feed already exists), looks like this (lines truncated here
for display):
0000008F91D0401CAF5BC063F29310C02E40D89F|113|08X3|08O3|03O3|101|02H1|44|2|Y|000000001001000|M|O|01|S||||||||1||||||
000002A365739E99657CD84AB646637A9E5B66C9|363|20S3|07C3|04C3|451|10L1|70|1|Y|001000000000000|M|R|03|M|1|1||||||1||||
000002F7994DF919B73F4ACFB0AF659CD5C0A3E7|20G|07XG||03OG|26G|06MG||||000000000000000||||||||||||||||||||||||||||||||
Advantages:
- No "programming trick" needed to ingest. All fields are just
fields. Very many input routines, tools, and packages can
handle this format as is.
- If the ingestor is configurable:
- No recoding of export or import processes needed
- Downstream processes, though, may need recoding and/or
reconfiguration, to make use of the new data.
- No possibility of duplication as is possible with key/value
pairs; this format does not permit transmitting values that
conflict.
Disadvantages:
- This format is not self-documenting. To ingest the data, a
separate metadata store must be communicated to the ingesting
program, either at design/coding or configuration time. The
possibility does exist that the data layout may change, but
the metadata will not, creating an out-of-synchronization
condition.
Bloat:
- 5% improvement over key/value pairs.
- Sample data show that average line length of records stored
in this format is 404 characters, versus 421 characters
formatted as key/value pairs.
- The 210 delimiters per line are "waste" from an information
content point of view. However, this is more than offset by
eliminating the verbose keys.
- Internal bloat shows 48% data, 52% delimiters.
Delimited flat-file records with headers
Another option would look like this (lines truncated here for
display):
AshID|FieldName1|FieldName2|FieldName3|FieldName4|FieldName5|FieldName6|FieldName7|FieldName8|FieldName9|FieldName10|
0000008F91D0401CAF5BC063F29310C02E40D89F|113|08X3|08O3|03O3|101|02H1|44|2|Y|000000001001000|M|O|01|S||||||||1||||||
000002A365739E99657CD84AB646637A9E5B66C9|363|20S3|07C3|04C3|451|10L1|70|1|Y|001000000000000|M|R|03|M|1|1||||||1||||
000002F7994DF919B73F4ACFB0AF659CD5C0A3E7|20G|07XG||03OG|26G|06MG||||000000000000000||||||||||||||||||||||||||||||||
Advantages:
- Some input routines, tools, and packages can handle this
format as is (but see related disadvantage below).
- If the ingestor is configurable:
- No recoding of export or import processes needed
- Downstream processes, though, may need recoding and/or
reconfiguration, to make use of the new data.
- No possibility of duplication as above; this format does not
permit transmitting values that conflict.
- This format is self-documenting. Metadata are included along
with the data. Though there is a possibility that a developer
would change data columns without changing the header records,
this possibility is relatively slight.
Disadvantages:
- Some input routines, tools, and packages can not handle this
format as is, necessitating pre-processing and/or error
handling to pull of and/or discard the header record.
Bloat:
- Effectively the same as flat-file records without headers;
all we do is add one header record; a tiny relative addition
in the case of large files.
Positionally formatted flat files, no header records
Consider the following; a portion of a data feed that currently
exists (records truncated):
0000008F91D0401CAF5BC063F29310C02E40D89F|113|08X3|08O3|03O3|101|02H1|44|2|Y|000000001001000|M|O|01|S||||||||1
000002A365739E99657CD84AB646637A9E5B66C9|363|20S3|07C3|04C3|451|10L1|70|1|Y|001000000000000|M|R|03|M|1|1||||||1
Note how nicely the fields all line up. Examining the total sample
input data file, they don't all line up as perfectly as that, but
the sameness of format and occurrence of values is apparent. In
such a situation, the following data formatting option may be
used:
0000008F91D0401CAF5BC063F29310C02E40D89F11308X308O303O310102H1442Y000000001001000MO01S
1
000002A365739E99657CD84AB646637A9E5B66C936320S307C304C345110L1701Y001000000000000MR03M11
1
Advantages:
- This is, or at least may be, the most efficient of all our
options. The overhead of using spaces when particular data
values are not present, is minimal.
- Maximally easy to ingest using nearly any off-the
shelf/existing input routine.
Disadvantages:
- This looks old-fashioned! Though seemingly silly, we must
not discount this factor. This scheme predates both computers
and electronics, going all the way back to the Hollerith card
and the 1890 (no that is not a typo) U.S. census. No one will
ever look at a presentation of this scheme and react "cool!"
Even if it happens to be the best option, all things
considered.
- As with other headerless formats, the possibility does and
always will exist that column layouts could change, without
correspondingly changed metadata being transmitted
to/incorporated by the ingesting system.
Bloat:
- Possibly, near-zero - close to "as small as bloat can get".
But see also hybrid schemes.
Hybrid: Positionally formatted flat files followed by
key-value pairs (no header records)
Consider the following (extracted from actual sample data but
modified and edited, for length and to demonstrate the point):
00000AF26FC46AF0613133E783A99AC4F7E880BD|173|12B3|01C3|01C3|261|06M1|34|1|Y|000001000000000|M|O|01|S||1|1||1||||G|B|C|C|||G|||A||M|||||000000010000010000000|byr=1941|
00000C3FBE1125E0273D8C06C5F1B52DE722F82B|05G|19MG|
|02OG|28G|03MG| | | |000000000000000| | | | ||
| || |||| | | | ||| ||| || |||||000000000000000000000||
00000D35294BA9AC67E18F86174D08DD61E1639D|20G|07XG|12OG|03OG|18G|03MG|
| | |000000000000000| | | |S|| | || |||| | | | |||
||| || |||||000000000000000000000||
Again, we may advantageously remove delimiters, going to a
positional scheme. But note toward the end of the top line, the
value 1941, not present in other records. If there are enough
instances of this sort of thing (variant attribute availability)
then a hybrid scheme might be optimal. First, on the left side
(before the vertical bar character), come all the positionally
formatted data. Then come the key-value pairs. Like so:
00000AF26FC46AF0613133E783A99AC4F7E880BD17312B301C301C326106M1341Y000001000000000MO01S111GBCCGAM000000010000010000000|byr=1941
00000C3FBE1125E0273D8C06C5F1B52DE722F82B05G19MG
02OG28G03MG
000000000000000
000000000000000000000
00000D35294BA9AC67E18F86174D08DD61E1639D20G07XG12OG03OG18G03MG
000000000000000
S
000000000000000000000
Advantages:
- If ProdBase records consist of a mix of attributes that are:
- "very commonly present" and
- "sometimes present but with great variation,"
then this would be the most efficient of all our options. We use
the best of both worlds; skipping the overhead of both
delimiters and of keys when that is beneficial, but then, using
keys when (and only when) it is beneficial to do so.
Disadvantages:
- Custom input/parsing required. No off-the-shelf tool I know
of supports this.
- Metadata still required for the left hand data elements;
out-of-synch potential exists. As with other headerless
formats, the possibility/risk will always exist, that column
layouts could change, without correspondingly changed metadata
being transmitted to/incorporated by the ingesting system.
Bloat:
- Possibly, near-zero - close to "as small as bloat can get".
Encoded single values
Looking again at one of the (leading) options for formatting an
anonymized ProdBase extract (lines truncated here for display):
0000008F91D0401CAF5BC063F29310C02E40D89F|1270-11|1271-08X|1274-08O|1275-03O|1280-10|1281-02H|4151-44|4152-2
000002A365739E99657CD84AB646637A9E5B66C9|1270-36|1271-20S|1274-07C|1275-04C|1280-45|1281-10L|4151-70|4152-1
000002F7994DF919B73F4ACFB0AF659CD5C0A3E7|1270-20|1271-07X|1275-03O|1280-26|1281-06M|2507-00|2531-00
There is another scheme, that is already used at Anonom and could
be used in this instance. That is:
- encode all this information as single values
- each single value contains both a definitional and a data
element.
So, working from the above example:
- aaaaa means 1270-11
- aaaab means 1270-20
- aaaac means 1270-36
- aaaad means 1271-08X
- aaaae means 1271-20S
- and so on.
Obviously this is just a "toy" example and the real scheme would
use different mappings. But as long as the ProdBase information to
be stored and transmitted consists of a smallish set of enumerable
values (which would exclude storing information such as decimal
values), this scheme is possible.
Advantages:
- Variable-length records nicely supported.
- Order of data within a record is not important.
- New encodings may be added at any time
- No recoding of export or import processes needed
- Downstream processes, though, may need recoding and/or
reconfiguration, to make use of the new data.
Disadvantages:
- This scheme does still inhere the risk of
non-synchronization of metatdata and data. If the definitional
scheme ever changes, but that is not communicated to the
ingesting system, incorrect processing and interpretation will
result.
- Possibility of duplication
- There is nothing within the file structure itself that
prevents something like this (given the sample scheme shown
above, this is an internal contradiction):
000002F7994DF919B73F4ACFB0AF659CD5C0A3E7|aaaab|aaaac|
Bloat:
- This sort of scheme will almost certainly not be efficient
as regards data storage, compared to some others described
here. In the example shown here, using 5 alphanumeric
characters (which seems a plausible length), it therefore
takes 5 characters to express what is expressed in just one
character in some of the other schemes. Which works out to 80%
bloat. A better analysis, using sample data, I have not
carried out.


from abc import ABCMeta, abstractmethod
import torch
from six import add_metaclass
[docs]@add_metaclass(ABCMeta)
class Distribution(object):
"""
Base class for parameterized probability distributions.
Distributions in Pyro are stochastic function objects with `.sample()` and `.log_pdf()` methods.
Pyro provides two versions of each stochastic function:
`(i)` lowercase versions that take parameters::
x = dist.bernoulli(param) # Returns a sample of size size(param).
p = dist.bernoulli.log_pdf(x, param) # Evaluates log probability of x.
and `(ii)` UpperCase distribution classes that can construct stochastic functions with
fixed parameters::
d = dist.Bernoulli(param)
x = d() # Samples a sample of size size(param).
p = d.log_pdf(x) # Evaluates log probability of x.
.. note::
Parameters and data should be of type `torch.autograd.Variable` and all
methods return type `torch.autograd.Variable` unless otherwise noted.
**Tensor Shapes**:
Distributions provide a method `.shape()` for the tensor shape of samples::
x = d.sample(*args, **kwargs)
assert x.shape == d.shape(*args, **kwargs)
Pyro distinguishes two different roles for tensor shapes of samples:
- The leftmost dimension corresponds to iid *batching*, which can be
treated specially during inference via the `.batch_log_pdf()` method.
- The rightmost dimensions correspond to *event shape*.
These shapes are related by the equation::
assert d.shape(*args, **kwargs) == (d.batch_shape(*args, **kwargs) +
d.event_shape(*args, **kwargs))
Distributions provide a vectorized `.batch_log_pdf()` method that evaluates
the log probability density of each event in a batch independently,
returning a tensor of shape `d.batch_shape() + (1,)`::
x = d.sample(*args, **kwargs)
assert x.shape == d.shape(*args, **kwargs)
log_p = d.batch_log_pdf(x, *args, **kwargs)
assert log_p.shape == d.batch_shape(*args, **kwargs) + (1,)
Distributions may also support broadcasting of the `.log_pdf()` and
`.batch_log_pdf()` methods, which may each be evaluated with a sample
tensor `x` that is larger than (but broadcastable from) the parameters.
In this case, `d.batch_shape()` will return a shape that is broadcastable to
`d.batch_log_pdf().shape`. For example::
x = d.sample()
xx = torch.stack([x, x])
d.batch_log_pdf(xx) + torch.zeros(d.batch_shape() + (1,)) # Broadcast.
**Implementing New Distributions**:
Derived classes must implement the following methods: `.sample()`,
`.batch_log_pdf()`, `.batch_shape()`, and `.event_shape()`, .
Discrete classes may also implement the `.enumerate_support()` method to improve
gradient estimates and set `.enumerable = True`.
**Examples**:
Take a look at the examples[link] to see how they interact with inference algorithms.
"""
reparameterized = False
enumerable = False
def __init__(self, reparameterized=None):
"""
Constructor for base distribution class.
:param bool reparameterized: Optional argument to override whether
instance should be considered reparameterized (by default, this
is decided by the class).
"""
if reparameterized is not None:
self.reparameterized = reparameterized
[docs] def batch_shape(self, *args, **kwargs):
"""
The left-hand tensor shape of samples, used for batching.
Samples are of shape `d().shape == d.batch_shape() + d.event_shape()`.
:return: Tensor shape used for batching.
:rtype: torch.Size
"""
raise NotImplementedError
[docs] def event_shape(self, *args, **kwargs):
"""
The right-hand tensor shape of samples, used for individual events.
Samples are of shape `d().shape == d.batch_shape() + d.event_shape()`.
:return: Tensor shape used for individual events.
:rtype: torch.Size
"""
raise NotImplementedError
[docs] def event_dim(self, *args, **kwargs):
"""
:return: Number of dimensions of individual events.
:rtype: int
"""
return len(self.event_shape(*args, **kwargs))
[docs] def shape(self, *args, **kwargs):
"""
The tensor shape of samples from this distribution.
Samples are of shape `d().shape == d.batch_shape() + d.event_shape()`.
:return: Tensor shape of samples.
:rtype: torch.Size
"""
return self.batch_shape(*args, **kwargs) + self.event_shape(*args, **kwargs)
def __call__(self, *args, **kwargs):
"""
Samples a random value (just an alias for `.sample(*args, **kwargs)`).
For tensor distributions, the returned Variable should have the same `.size()` as the
parameters.
:return: A random value.
:rtype: torch.autograd.Variable
"""
return self.sample(*args, **kwargs)
[docs] @abstractmethod
def sample(self, *args, **kwargs):
"""
Samples a random value.
For tensor distributions, the returned Variable should have the same `.size()` as the
parameters.
:return: A random value or batch of random values (if parameters are
batched). The shape of the result should be `self.size()`.
:rtype: torch.autograd.Variable
"""
raise NotImplementedError
[docs] def log_pdf(self, x, *args, **kwargs):
"""
Evaluates total log probability density of a batch of samples.
:param torch.autograd.Variable x: A value.
:return: total log probability density as a one-dimensional torch.autograd.Variable of size 1.
:rtype: torch.autograd.Variable
"""
return torch.sum(self.batch_log_pdf(x, *args, **kwargs))
[docs] @abstractmethod
def batch_log_pdf(self, x, *args, **kwargs):
"""
Evaluates log probability densities for each of a batch of samples.
:param torch.autograd.Variable x: A single value or a batch of values
batched along axis 0.
:return: log probability densities as a one-dimensional
`torch.autograd.Variable` with same batch size as value and params.
The shape of the result should be `self.batch_size()`.
:rtype: torch.autograd.Variable
"""
raise NotImplementedError
[docs] def enumerate_support(self, *args, **kwargs):
"""
Returns a representation of the parametrized distribution's support.
This is implemented only by discrete distributions.
:return: An iterator over the distribution's discrete support.
:rtype: iterator
"""
raise NotImplementedError("Support not implemented for {}".format(type(self)))
[docs] def analytic_mean(self, *args, **kwargs):
"""
Analytic mean of the distribution, to be implemented by derived classes.
Note that this is optional, and currently only used for testing distributions.
:return: Analytic mean.
:rtype: torch.autograd.Variable.
:raises: NotImplementedError if mean cannot be analytically computed.
"""
raise NotImplementedError("Method not implemented by the subclass {}".format(type(self)))
[docs] def analytic_var(self, *args, **kwargs):
"""
Analytic variance of the distribution, to be implemented by derived classes.
Note that this is optional, and currently only used for testing distributions.
:return: Analytic variance.
:rtype: torch.autograd.Variable.
:raises: NotImplementedError if variance cannot be analytically computed.
"""
raise NotImplementedError("Method not implemented by the subclass {}".format(type(self)))


Trudeau seeks to keep eyes on Prairies with new role for Winnipeg's Jim Carr
OTTAWA - Prime Minister Justin Trudeau carved out a new role in his government Wednesday designed to ensure voices on the Prairies are heard in Ottawa.
Former cabinet minister Jim Carr, who represents a Winnipeg riding, has been named as Trudeau's "special representative" for the Prairie provinces.
The move follows the Liberals complete shutout in Alberta and Saskatchewan in the October federal election, including the loss of two cabinet ministers.
That raised concerns about how voices from those provinces would have a say around the cabinet table.
The Liberals also lost three seats in Manitoba.
READ MORE: Trudeau turns to B.C. MP with Saskatchewan roots to helm tricky climate ministry
"The Government of Canada represents Canadians in every part of the country. That is why the prime minister has asked Jim Carr to serve as his special representative for the Prairies," Trudeau's office said in a news release announcing the move.
"Born and raised in Winnipeg, he will ensure that the people of Alberta, Saskatchewan, and Manitoba have a strong voice in Ottawa."
Carr formerly served as both natural resources minister and minister for international trade diversification, two portfolios exceptionally top of mind in the Prairies, given struggles in the energy sector and ongoing trade disputes affecting Canadian farmers and producers.
Shortly after the election, Carr said he had received a diagnosis of a form of blood cancer.
There had been questions about his ability to keep playing a major role in Trudeau's cabinet as he undergoes treatment.
READ MORE: Who's who in Justin Trudeau's cabinet: some new, some old and others in new places
His appointment came as part of a broad cabinet shuffle for the Liberal government that also included naming Chrystia Freeland the deputy prime minister and intergovernmental affairs minister.
Freeland, though an MP for a Toronto riding, was born in Alberta.
She'd previously served as Trudeau's foreign affairs ministers, and now will need to bring her diplomatic skills to bear on the home front at time when provincial-federal relationships are exceptionally rocky due to issues including the federal carbon tax, immigration and the Trans Mountain pipeline.
Other MPs from the West who nabbed a spot in cabinet include Winnipeg's Dan Vandal, appointed minister of Northern Affairs. British Columbia's Jonathan Wilkinson was shuffled to Environment from Fisheries, and Carla Qualtrough, also from B.C., was moved to Employment, Workforce Development and Disability Inclusion from her previous role as minister of public services, procurement and accessibility.


FF3 Jobs
Expand All Images | Collapse All Images
|
| NAME: Bard |
| OVERVIEW: See Bard. |
|
| < |
| NAME: Black Belt |
| OVERVIEW: See Monk. |
|
|
| NAME: Dragoon |
| OVERVIEW: See Dragoon. |
|
|
| NAME: Freelancer |
| OVERVIEW: This class only exists in the DS version and replaces the Onion Knight in the beginning of the game. Unlike its predecessor, the freelancer can use a wide variety of weapons and Level 1 White and Black magic. But that's about it. |
| WEAPONS: ??? |
| ABILITIES/MAGIC:
Black Magic - Use Black Magic
White Magic - Use White Magic
???
Item - Use an item from inventory
|
| ATTRIBUTES: |
|
|
| NAME: Hunter |
| OVERVIEW: See Archer. |
|
|
| NAME: Knight |
| OVERVIEW: See Knight. |
|
| FF3 |
|
| NAME: M. Knight / Dark Knight |
| OVERVIEW: The Mystic (or Magic) Knight that can use White Magic, but only from the menu. It is the only class that can prevent enemies from splitting. This class was changed into the Dark Knight for the DS version, but retains the same functionality. |
| WEAPONS: Ashura, Kotetsu, Kiku, Full Moon, Masamune, Ragnarok |
| ABILITIES/MAGIC:
Fight - Attack with equipped weapon
Defend - Increase defense for one turn
Magic - Cast magic spell
Item - Use an item from inventory
|
| ATTRIBUTES: |
|
|
| NAME: Monk |
| OVERVIEW: See Monk. |
|
|
| NAME: Ninja |
| OVERVIEW: See Ninja. |
|
|
| NAME: Sage |
| OVERVIEW: See Sage. |
|
|
| NAME: Scholar |
| OVERVIEW: See Scholar. |
|
|
| NAME: Thief |
| OVERVIEW: See Thief. |
|
| < |
| NAME: Viking |
| OVERVIEW: Looks sort of like a dward, and may have been a precursor to the Berserker. |
| WEAPONS: Thor Hammer, Triton Hammer, Battle Axe, GreatAxe, Morning Star, Tomahawk Axe |
| ABILITIES/MAGIC:
Fight - Attack with equipped weapon
Defend - Increase defense for one turn
Run - Run away from battle
Item - Use an item from inventory
|
| ATTRIBUTES: High defense |
|
|
| NAME: Warrior |
| OVERVIEW: See Fighter. |
|
Final Fantasy, all games and animation bearing the Final Fantasy name, and all characters in said games or animation are copyright their respective creators, including but not limited to Squaresoft, Square Enix, Square EA, Tokyo TV, and ADV Films.


I'm from Engineering with Business. 19 this year. I came to SP after a year in JC. I like watching anime and movies. Here are some food photos I have taken to fill up the space!


I asked this during my presentation on the MySQL Conference this year. And I got a unanimous answer from the crowd. Take a moment to think this over, before coming up with the answer. Meanwhile, an intermezzo.
Tam dam dam...
Pom pom Pom pom Pom pom...
If your answer is that the most basic privilege an account can be assigned with is the USAGE privilege, you are right!
And then again, you're also wrong.
Technically, USAGE is the right answer. Conceptually, there's something far more fundamental than USAGE. An account with only USAGE privilege cannot do much, right? Well, I argue on that as well, but bear with me. How did that user get to login in the first place?
That's right, the USAGE privilege first and foremost allows one to login. I wrote on this before, and I cannot stress this enough: there should be a LOGIN privilege for MySQL, one which can be turned off with REVOKE.
Can you REVOKE the USAGE privilege? You cannot. Once an account exists, it is allowed to login and do stuff. Actually:
USAGE = LOGIN + USE + ABUSE YOUR SYSTEM
Which is why ABUSAGE is a more fitting name for this privilege. There is no justification to the many things a user can do with USAGE.
Am I exaggerating? What does USAGE allow one to do? Let's look at some unconventional usage:
SELECT benchmark(10000000000000000, sin(sqrt(rand()))); +-------------------------------------------------+ | benchmark(10000000000000000, sin(sqrt(rand()))) | +-------------------------------------------------+ | 0 | +-------------------------------------------------+ 1 row in set (gazillion seconds to complete, one core down)
SELECT DISTINCT 0 * COUNT(*) AS result FROM INFORMATION_SCHEMA.COLLATIONS c0, INFORMATION_SCHEMA.COLLATIONS c1, INFORMATION_SCHEMA.COLLATIONS c2, INFORMATION_SCHEMA.COLLATIONS c3, INFORMATION_SCHEMA.COLLATIONS c4, INFORMATION_SCHEMA.COLLATIONS c5, INFORMATION_SCHEMA.COLLATIONS c6, INFORMATION_SCHEMA.COLLATIONS c7, INFORMATION_SCHEMA.COLLATIONS c8, INFORMATION_SCHEMA.COLLATIONS c9 GROUP BY c1.COLLATION_NAME, c7.SORTLEN ; +--------+ | result | +--------+ | 0 | +--------+ 1 row in set (yet again gazillion seconds to complete, with huge disk temporary table)
SELECT COUNT(DISTINCT SLEEP(1000)) FROM INFORMATION_SCHEMA.TABLES; +-----------------------------+ | COUNT(DISTINCT SLEEP(1000)) | +-----------------------------+ | 1 | +-----------------------------+ 1 row in set (want to gamble how much time your DB will spend in complete lockdown?)
And I should also mention open many concurrent connections (thankfully there is syntax to limit this!).
comments powered by Disqus


| 832 | (A) | when the derke was done and the day sprongen |
| 836 | (C) | whenne þe nyght was doone . & þe day spronge |
| (D) | ---- no text ---- | |
| (E) | ---- no text ---- | |
| (Ex) | ---- no text ---- | |
| 853 | (L) | whan þe derk was doun & þe day spryngen |
| 775 | (P) | when þe nyght was done & þe daye sprongen |
| (U) | ---- no text ---- | |
| (V) | ---- no text ---- |


Hello! This is where I'll be compiling basic information and pictures of my main characters.
This whole thing is quite under construction and is structured about as reliably as a balloon in a sewing supply store. Okay it's not that bad but I just wanted to use that metaphor! Thank you for viewing and taking interest in my characters~