01.03.2017 19:22, Dmitry Yemanov wrote:
>> 01.03.2017 19:50, Vlad Khorsun wrote:
..
>> Also, I prefer to avoid to return as a string something that is not a string.
>
> Agreed here. From another side, I don't like polluting the global
> namespace with non-standard but reserved keywords.
Same
I just looked at the git commit, iirc the implementation assumed start to be
zero-based (I believe in parse.y 1 is subtracted from the start to match that
expectation), in your implementation on 10350 in ExprNodes you set sStart to 1,
that should be 0, if I'm not mistaken.
Mark
- Bericht
01.03.2017 19:50, Vlad Khorsun wrote:
>
>>> If this variable is added as a context variable into "SYSTEM" namespace,
>>> simple
>>> "START_TIMESTAMP" should be enough
>>
>> It could be confused with attachment-start timestamp.
>
> I thought it is clear that ticket is about new system contex
01.03.2017 17:38, Dmitry Yemanov wrote:
> It could be confused with attachment-start timestamp.
Add both. ;-)
--
WBR, SD.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites,
01.03.2017 19:33, Dimitry Sibiryakov wrote:
> If this variable is added as a context variable into "SYSTEM" namespace,
> simple
> "START_TIMESTAMP" should be enough
It could be confused with attachment-start timestamp.
Dmitry
01.03.2017 17:24, Vlad Khorsun wrote:
> As for the name, i prefer CURRENT_TRANSACTION_TIME or
> CURRENT_TRANSACTION_TIMESTAMP.
If this variable is added as a context variable into "SYSTEM" namespace,
simple
"START_TIMESTAMP" should be enough, as none of transaction-related variables
there
01.03.2017 17:24, Vlad Khorsun wrote:
>Is there any objection to add it into upcoming v3.0.2 and v4 ?
3.0 is supposed to be a feature-stable branch.
--
WBR, SD.
--
Check out the vibrant tech community on one
01.03.2017 9:33, Karol Bieniaszewski (JIRA) wrote:
> Add context variable about transaction start timestamp
> --
>
> Key: CORE-5493
> URL: http://tracker.firebirdsql.org/browse/CORE-5493
> Project:
I will try and do my best to revisit the MacOS build once 3.0.2 comes out
(which is
likely to be very shortly).
Regards
Paul
--
Check out the vibrant tech community on one of the world's most
engaging tech sites,
Yes, Mac build of Firebird was the hardest of all our software modules so far
(we're planning to use it as embedded database).
My build notes are very similar to yours, a few things that I noted down are:
autogen.sh I had to add --disable-raw-devices, because that module did not
compile for
On 01/03/2017 01:17, Dmitry Yemanov wrote:
> 01.03.2017 00:18, Dmitry Kuzmenko wrote:
>> As to BLR, I don't think that eliminating BLR is a good idea. You need
>> to have same or better speed of interpreting SQL
> Execution time does not depend on whether it's BLR or SQL. Parsing time
> (read:
01.03.2017 11:20, Dmitry Yemanov wrote:
> 28.02.2017 17:18, Michal Kubecek wrote:
>>
>> as my Hackweek project, I played with struct rem_port and tried to turn
>> it into class hierarchy with virtual functions. The plan is to use this
>> to implement listening on multiple sockets (CORE-5219) and
At least a description of the complicated settings build would be very
useful. I several times started to build FB3 and master on my mac and
cried :)
2017-03-01 12:11 GMT+03:00 Paul Beach :
> A question by Vlad has prompted me to write this brief message...
>
> Some of you
28.02.2017 17:18, Michal Kubecek wrote:
>
> as my Hackweek project, I played with struct rem_port and tried to turn
> it into class hierarchy with virtual functions. The plan is to use this
> to implement listening on multiple sockets (CORE-5219) and possibly also
> AF_UNIX socket support but I
A question by Vlad has prompted me to write this brief message...
Some of you may have noticed that we have no official installer for
Firebird 3.x on MacOSX... to date thats been down to me, and on
my todo list when I get enough time. I have started work on it
but I haven't been able to finish
15 matches
Mail list logo