maria-discuss team mailing list archive

[Peter Laursen <peter_laursen@xxxxxxxxxx>]

And a little more RAM than I wrote: 32 GB!

On Tue, Mar 3, 2015 at 2:41 PM, Peter Laursen <peter_laursen@xxxxxxxxxx>
wrote:

> It is actually a 512 MB DDR3-RAM Geforce card - but it hardly matters, I
> think. --Peter
>
> On Tue, Mar 3, 2015 at 2:30 PM, Justin Swanhart <greenlion@xxxxxxxxx>
> wrote:
>
>> After you debug you proc you kinda have to replace the non buggy one.  In
>> production.  While people are using it.  Unless you version your whole code
>> base and push out a new version to use a new name.
>>
>> Sent from my iPhone
>>
>> On Mar 3, 2015, at 6:22 AM, Peter Laursen <peter_laursen@xxxxxxxxxx>
>> wrote:
>>
>> If this "You can't drop a busy proc in production to replace it" was for
>> me,  then note the passage from my blog:
>>
>> "you can add a IN-parameter *(debug: integer)* to a Stored Procedure
>> paramer-list and *CALL mysp(….,0|1)* what would then control if the
>> stored program should enter or bypass debugging code when executing". This
>> is the best workaround I've found.
>>
>> On Tue, Mar 3, 2015 at 2:17 PM, Justin Swanhart <greenlion@xxxxxxxxx>
>> wrote:
>>
>>> You can't drop a busy proc in production to replace it.  Many users
>>> would get an error.  This is the same reason views have had CoR for so
>>> long. So yes it is a big deal!
>>>
>>> Anyway, what I want most are Antony Curtis' stored proc / parser changes
>>> (mdev 820 if I'm not mistaken).  I am especially interested in table
>>> functions and external stored routines.
>>>
>>> I'd also like to discuss window functions too.  I've implemented them in
>>> shard-query and have ideas about how to implement them in the server, but
>>> pluggable parser would be really useful here.
>>>
>>> --Justin
>>>
>>> Sent from my iPhone
>>>
>>> > On Mar 3, 2015, at 2:48 AM, Sergei Golubchik <serg@xxxxxxxxxxx> wrote:
>>> >
>>> > Hi, Federico!
>>> >
>>> >> On Mar 03, Federico Razzoli wrote:
>>> >> Reading 10.0.3 release notes:
>>> >>
>>> >> https://mariadb.com/kb/en/mariadb/mariadb-1013-release-notes/
>>> >>
>>> >> I see that IF EXISTS, IF NOT EXISTS and OR REPLACE are now almost
>>> >> consistent. "Almost" means that... OR REPLACE still doesn't apply to
>>> >> stored procedures, functions, triggers, events.
>>> >
>>> > Support for events is already pushed (albeit after 10.1.3).
>>> > Support for triggers will be pushed any day now (already reviewed and
>>> > approved, so there's no more work left on it). I suppose that stored
>>> > procedures and functions will follow soon.
>>> >
>>> > This was a GSoC 2014 project that added support for these clauses to
>>> > *all* objects. It's just being pushed piecewise, object by object.
>>> >
>>> >> Recently, during a public session, a PostgreSQL user asked me if
>>> >> MariaDB supports stored procedures - in his opinion, MySQL doesn't, no
>>> >> matter what the manual says. Unfortunately my answer was that MariaDB
>>> >> support for stored procedure is the same as MySQL ("so the answer is
>>> >> no", he said).
>>> >
>>> > I don't understand what exactly missing feature that user had in mind.
>>> > It couldn't have been "CREATE OR REPLACE", this seems so minor.
>>> > Or was it?
>>> >
>>> > Regards,
>>> > Sergei
>>> >
>>> > _______________________________________________
>>> > Mailing list: https://launchpad.net/~maria-discuss
>>> > Post to     : maria-discuss@xxxxxxxxxxxxxxxxxxx
>>> > Unsubscribe : https://launchpad.net/~maria-discuss
>>> > More help   : https://help.launchpad.net/ListHelp
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~maria-discuss
>>> Post to     : maria-discuss@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~maria-discuss
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>