Nihal Dindar | 3 Mar 15:31 2008
Picon

Extension to the MySQL Language

Hey,

For my master thesis, I need to extend the MySQL language. I added my 
keywords in the lex.h file and modified the sql_yacc file accordingly. 
Afterwards, I run the 'make' command in the sql directory. The result is 
following:

bison -y -p MYSQL  -d --verbose sql_yacc.yy
conflicts: 281 shift/reduce
sql_yacc.yy: expected 279 shift/reduce conflicts
make: *** [sql_yacc.cc] Error 1

Can anyone help me?

Best,

Nihal

--

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals?unsub=gcdmd-internals <at> m.gmane.org

Chad MILLER | 3 Mar 16:01 2008
Picon

Re: Extension to the MySQL Language


On 3 Mar 2008, at 09:31, Nihal Dindar wrote:

> Hey,
>
> For my master thesis, I need to extend the MySQL language. I added  
> my keywords in the lex.h file and modified the sql_yacc file  
> accordingly. Afterwards, I run the 'make' command in the sql  
> directory. The result is following:
>
> bison -y -p MYSQL  -d --verbose sql_yacc.yy
> conflicts: 281 shift/reduce
> sql_yacc.yy: expected 279 shift/reduce conflicts
> make: *** [sql_yacc.cc] Error 1

A shift/reduce conflict means that you have some ambiguity in your  
new additions, which generally means it's not programmed well; most  
all our 279 so far really reduce down to one empty-string rule which  
is proving hard to destroy.  Are you certain that you can not remove  
your new ambiguity?  See the resulting sql/sql_yacc.output for hints.

If you are certain, search sql/sql_yacc.yy for the number "279".

- chad

--
Chad Miller, Software Developer                         chad <at> mysql.com
MySQL Inc., www.mysql.com
Orlando, Florida, USA                                13-20z,  UTC-0400
Office: +1 408 213 6740                         sip:6740 <at> sip.mysql.com
(Continue reading)

Stefan Hinz | 4 Mar 16:37 2008
Picon

MySQL University session on March 6

Hi,

this Thursday, Alexander Barkov will give a MySQL University session:

http://forge.mysql.com/wiki/How_to_Add_a_Collation

Please register for this session by filling in your name on the session
Wiki page. Registering is not required but appreciated. That Wiki page
also contains a section to post questions. Please use it!

MySQL University sessions normally start at 13:00 UTC (summer) or 14:00
UTC (winter); see: http://forge.mysql.com/wiki/MySQL_University for more
time zone information.

Those planning to attend a MySQL University session for the very first
time should probably read the instructions for attendees,
http://forge.mysql.com/wiki/Instructions_for_Attendees.

Next MySQL University sessions:

March 13: Checking Threading and Locking With Helgrind (Stewart Smith)
March 20: Building MySQL Client Applications (Hartmut Holzgraefe)
March 27: EC2 (Brian Aker)
April 3: Checking Performance with Kchachegrind (Stewart Smith)

See http://forge.mysql.com/wiki/MySQL_University#Upcoming_Sessions for
the complete list.

--

-- 
Regards,
(Continue reading)

Timothy P Clark | 4 Mar 16:50 2008
Picon

Reliably identifying primary keys


Hi,

The storage engine that I am working on is required to treat primary keys
differently than other indexes. As well, we would like our SE to be able to
support online adding/dropping of indexes. The problem is that I'm
uncertain how to reliably identify whether a key that the storage engine is
given is actually a primary key. There appear to be two methods for
determing whether a key is the primary key: using table->s->primary_key,
and using the name of the key, which appears to always be "PRIMARY" for the
primary key.

I assumed that the first option (table->s->primary_key) would be the most
reliable method. However, when a key is added to an existing table, this
information is not updated before handler::add_index is called.
Consequently, it seems that I am required to rely on the name of the key (
== "PRIMARY") to determine whether it is the primary key.

Can I always rely on the name of the key? If not, what can I use in
add_index to know whether the key should be the primary key?

Thank you,
Tim Clark

--

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals?unsub=gcdmd-internals <at> m.gmane.org

(Continue reading)

Stefan Hinz | 4 Mar 21:01 2008
Picon

MySQL University session on March 6

Hi,

sorry for a second mail on the same subject, but I forgot to mention
that Alexander Barkov's MySQL University session

http://forge.mysql.com/wiki/How_to_Add_a_Collation

will be an IRC-only question-and-answer session.

So please visit the session page, look at the presentation uploaded
there, and come to the session with a bunch of questions!

-- 
Regards,

Stefan Hinz <stefan <at> mysql.com>, MySQL AB Documentation Manager
Berlin, Germany (UTC +1:00/winter, +2:00/summer)
Skype:stefanhinz Cell:+491777841069 Desk:+493082702940 Fax:+493082702941

--

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals?unsub=gcdmd-internals <at> m.gmane.org

Michael Widenius | 5 Mar 08:40 2008
Picon

re: Reliably identifying primary keys


Hi!

>>>>> "Timothy" == Timothy P Clark <Timothy> writes:

Timothy> Hi,

Timothy> The storage engine that I am working on is required to treat primary keys
Timothy> differently than other indexes. As well, we would like our SE to be able to
Timothy> support online adding/dropping of indexes. The problem is that I'm
Timothy> uncertain how to reliably identify whether a key that the storage engine is
Timothy> given is actually a primary key. There appear to be two methods for
Timothy> determing whether a key is the primary key: using table->s->primary_key,
Timothy> and using the name of the key, which appears to always be "PRIMARY" for the
Timothy> primary key.

Timothy> I assumed that the first option (table->s->primary_key) would be the most
Timothy> reliable method.

Yes, this is the correct way to do this.

Timothy> However, when a key is added to an existing table, this
Timothy> information is not updated before handler::add_index is called.

For add index you have to reply on the name as at this point the new
table definition is not yet active.

Timothy> Consequently, it seems that I am required to rely on the name of the key (
Timothy> == "PRIMARY") to determine whether it is the primary key.

(Continue reading)

KishoreKumar Bairi | 5 Mar 09:32 2008
Picon

adding LUA support to mysql command line client

Hello,

First thing I would like to ask is from few days the activity of this
list is reduced. Is there any specific reason for this?
and comming to my query,
Mr. JimWinstead has suggested "Add Lua support to the mysql
command-line client" as SOC project.
Kindly can any one give more information regarding this project.
Especially I would like to know, What all advantages we get from
addition of this feature?
I feel that this feature will serve the same purpose of SHELL SCRIPTING in UNIX.
and What all modules to be added/changed?
Please give some information to get started. I am interested in this.

I'm not a native English speaker. kindly forgive me for my english.

regards
--
KishoreKumar

--

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals?unsub=gcdmd-internals <at> m.gmane.org

Heikki Tuuri | 5 Mar 14:07 2008
Picon

Innobase looking for guru-level software engineers

Innobase Oy is looking for guru-level software engineers

If you are interested in a career at Innobase Oy, please send a resume 
to heikki.tuuri at oracle.com.
We are offering a very competitive salary.

Our general requirements for applicants are:
-Must be able to write well-documented C code. Fluent in English.
-A MSc or a PhD degree or equivalent. Knowledge of MySQL or Oracle. 
Knowledge of database technology.

InnoDB is a transactional database engine that is embedded inside MySQL. 
Both MySQL and InnoDB are open source software. MySQL has an estimated 4 
million users worldwide.

Innobase Oy is a subsidiary of Oracle Corporation.
MySQL is a trademark of Sun Microsystems.

--

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals?unsub=gcdmd-internals <at> m.gmane.org

Timothy P Clark | 5 Mar 15:23 2008
Picon

re: Reliably identifying primary keys


Michael Widenius <monty <at> mysql.com> wrote on 03/05/2008 01:40:39 AM:

>
> Hi!
>
> >>>>> "Timothy" == Timothy P Clark <Timothy> writes:
>
> Timothy> Hi,
>
> Timothy> The storage engine that I am working on is required to
> treat primary keys
> Timothy> differently than other indexes. As well, we would like our
> SE to be able to
> Timothy> support online adding/dropping of indexes. The problem is that
I'm
> Timothy> uncertain how to reliably identify whether a key that the
> storage engine is
> Timothy> given is actually a primary key. There appear to be two methods
for
> Timothy> determing whether a key is the primary key: using
> table->s->primary_key,
> Timothy> and using the name of the key, which appears to always be
> "PRIMARY" for the
> Timothy> primary key.
>
> Timothy> I assumed that the first option (table->s->primary_key)
> would be the most
> Timothy> reliable method.
>
(Continue reading)

Prakash Velayutham | 5 Mar 15:39 2008

LDAP authentication for MySQL

Hello All,

I am looking for using LDAP authentication for MySQL, but don't think  
it is available already. The most relevant thread I can see is http://lists.mysql.com/eventum-users/1194?login=1

Does anyone know if this is nearing completion?

Also, I could help with coding it up if needed, but please keep in  
mind that I do not know MySQL code well.

Thanks,
Prakash

--

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals?unsub=gcdmd-internals <at> m.gmane.org


Gmane