On 01/01/2013 03:12, Greg Sabino Mullane wrote:
Thanks for doing this work, it's good to see someone poking at
this. +1 for getting the DBDs somewhat consistent, although it
may be tricky as some (looking at you, MySQL!) play more fast and
loose with their data type definitions than others. :)
On 08/01/13 16:58, Lyle wrote:
On 08/01/2013 13:19, Martin J. Evans wrote:
FYI
In ODBC a value may be bound as a numeric and the numeric returned is then a
structure:
typedef struct tagSQL_NUMERIC_STRUCT
{
SQLCHAR precision;
SQLSCHARscale;
SQLCHAR
On 08/01/2013 13:19, Martin J. Evans wrote:
FYI
In ODBC a value may be bound as a numeric and the numeric returned is
then a structure:
typedef struct tagSQL_NUMERIC_STRUCT
{
SQLCHAR precision;
SQLSCHARscale;
SQLCHAR sign; /* 1=pos 0=neg */
On 08/01/13 12:17, Lyle wrote:
On 05/01/2013 20:49, Darren Duncan wrote:
On 2013.01.05 5:39 AM, Lyle wrote:
I'm not overly familiar with Perl's internal handling of number. I guess if you
have DECIMAL from a character string Perl will switch it out to an approximate
the moment you do a calculat
On 05/01/2013 20:49, Darren Duncan wrote:
On 2013.01.05 5:39 AM, Lyle wrote:
I'm not overly familiar with Perl's internal handling of number. I
guess if you
have DECIMAL from a character string Perl will switch it out to an
approximate
the moment you do a calculation on it. Furthermore if the D
On 07/01/2013 13:08, Lyle wrote:
On 07/01/2013 10:43, H.Merijn Brand wrote:
On Sun, 30 Dec 2012 02:53:33 +, Lyle
wrote:
Hi All,
Whilst working on another project it made sense to write a tool for
comparing the various RDBMSs...
Very useful indeed, but I'm afraid that it also depends
On 07/01/2013 10:43, H.Merijn Brand wrote:
On Sun, 30 Dec 2012 02:53:33 +, Lyle
wrote:
Hi All,
Whilst working on another project it made sense to write a tool for
comparing the various RDBMSs...
Very useful indeed, but I'm afraid that it also depends on the version
of the database(s).
On Sun, 30 Dec 2012 02:53:33 +, Lyle
wrote:
> Hi All,
>Whilst working on another project it made sense to write a tool for
> comparing the various RDBMSs. I'm talking about the database management
> systems themselves, not databases within them. So far I've done parts
> that use $dbh->
On 2013.01.05 5:39 AM, Lyle wrote:
On 05/01/2013 10:41, Darren Duncan wrote:
Since the SQL standard, as well as some other programming languages, define
"decimal" as being exact numeric, then it is absolutely wrong to map them to
either FLOAT or DOUBLE. In fact, in Perl 5 the only native type t
On 05/01/2013 10:41, Darren Duncan wrote:
My understanding about Postgres either compressing strings or using
"toast" segments for longer ones is that this is just an internal
implementation detail and that user-facing concepts like data types
should be ignoring these differences. Character da
On 2013.01.04 4:17 PM, Lyle wrote:
On 01/01/2013 03:12, Greg Sabino Mullane wrote:
Lyle wrote:
Similar situation for PostgreSQL character.
Yep.
Reviewing the PostgreSQL documentation on CHARACTER it mentions things
like short, long and very long character strings, but lacks detail so
I've ema
On 01/01/2013 03:12, Greg Sabino Mullane wrote:
Lyle wrote:
I'm sure there are more things that look a bit odd or out of place. I'm
not sure whether there is good reasoning behind them, or whether the DBD
developers have been doing a best guess and we might possibly want to
consider making thing
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
TL;DR: it's a rat's nest, with both solid reasoning and wild guesses.
Lyle wrote:
> I'm sure there are more things that look a bit odd or out of place. I'm
> not sure whether there is good reasoning behind them, or whether the DBD
> developer
I'm sorry. Me and Darren are having this conversation on two separate
lists (this one and TTM) that we are both part of, but have a
substantially different subscriber base. This response was supposed to
have gone to TTM.
Lyle
On 30/12/2012 16:45, Lyle wrote:
On 30/12/2012 04:19, Darren Dunc
On 30/12/2012 04:19, Darren Duncan wrote:
Yes, that is useful.
I think you should add a column such that your leftmost column is some
canonical type name you made for the report, and have the SQL standard
name(s) in a separate column like the ODBC standard names are.
This works best when no
On 30/12/2012 04:19, Darren Duncan wrote:
Yes, that is useful.
I think you should add a column such that your leftmost column is some
canonical type name you made for the report, and have the SQL standard
name(s) in a separate column like the ODBC standard names are.
As far as I understand t
Yes, that is useful.
I think you should add a column such that your leftmost column is some canonical
type name you made for the report, and have the SQL standard name(s) in a
separate column like the ODBC standard names are.
This works best when no one list is a superset of the others, which
17 matches
Mail list logo
