On Sat, 16 Feb 2008, Ken Johanson wrote:
> Tom Lane wrote:
>
> > Hm, good point, so really we ought to have a separate casting path for
> > numeric types to char(n). However, this section still doesn't offer
> > any support for the OP's desire to auto-size the result; it says
> > that you get an
On Sat, 16 Feb 2008, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Tue, 12 Feb 2008, Tom Lane wrote:
> >> Also, section 6.10 defines an explicit cast to
> >> a fixed-length string type as truncating or padding to the target
> >> length (LTD):
>
> > Are you sure that's the cor
Ken Johanson <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hm, good point, so really we ought to have a separate casting path for
>> numeric types to char(n). However, this section still doesn't offer
>> any support for the OP's desire to auto-size the result; it says
>> that you get an error i
Tom Lane wrote:
Hm, good point, so really we ought to have a separate casting path for
numeric types to char(n). However, this section still doesn't offer
any support for the OP's desire to auto-size the result; it says
that you get an error if the result doesn't fit in the declared
length:
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Tue, 12 Feb 2008, Tom Lane wrote:
>> Also, section 6.10 defines an explicit cast to
>> a fixed-length string type as truncating or padding to the target
>> length (LTD):
> Are you sure that's the correct section to be using? Isn't that 6.10
> General
[Way behind on reading stuff - so I hope this wasn't covered later]
On Tue, 12 Feb 2008, Tom Lane wrote:
> Ken Johanson <[EMAIL PROTECTED]> writes:
> > For sake of interoperability (and using an API that requires String-type
> > hashtable keys), I'm trying to find a single CAST (int -> var/char)
Richard Huxton wrote:
What I couldn't figure out was what type MySQL was using. I mean, what
type is this?
mysql> SELECT cast(a as char) as achar FROM tt;
+---+
| achar |
+---+
| 1 |
| 10|
+---+
2 rows in set (0.00 sec)
Is it char(2)?
mysql> CREATE TEMPORARY TABLE ttchar0
Tom Lane wrote:
Richard Huxton <[EMAIL PROTECTED]> writes:
[ proof that cast(123 as char) actually produces varchar in mysql ]
Egad. I wonder if they think this is a feature?
Well, presumably its what all the other "convenient" (for Ken's
particular problem) databases do. The only alternat
Richard Huxton <[EMAIL PROTECTED]> writes:
> [ proof that cast(123 as char) actually produces varchar in mysql ]
Egad. I wonder if they think this is a feature?
regards, tom lane
---(end of broadcast)---
TIP 3: Have you che
Alvaro Herrera wrote:
Ken Johanson wrote:
Alvaro Herrera wrote:
If you are arguing that the spec's definition of the CHARACTER type is
not really very useful, I think you are going to find a lot of
supporters. You can send your complaints to the SQL committee; but
then, it is unlikely that thi
Ken Johanson wrote:
> Alvaro Herrera wrote:
>> If you are arguing that the spec's definition of the CHARACTER type is
>> not really very useful, I think you are going to find a lot of
>> supporters. You can send your complaints to the SQL committee; but
>> then, it is unlikely that this is going t
Alvaro Herrera wrote:
If you are arguing that the spec's definition of the CHARACTER type is
not really very useful, I think you are going to find a lot of
supporters. You can send your complaints to the SQL committee; but
then, it is unlikely that this is going to change anytime soon because
of
Ken Johanson wrote:
> Henceforth SELECT CAST(123 AS char) will and should undisputedly return '1'.
If you are arguing that the spec's definition of the CHARACTER type is
not really very useful, I think you are going to find a lot of
supporters. You can send your complaints to the SQL committee;
Andrew Sullivan wrote:
No, you're trying to convey that it is more benign/useful _to you_. Others
are arguing that they want to write conformant code, and don't much care
what MyOccasionallyReadTheSpec does. It's a pity that SQL conformance is
not better across systems, but surely the way to
On Tue, Feb 12, 2008 at 08:39:05PM -0700, Ken Johanson wrote:
> between 3rd party products (customer API and database x^n). I'm trying
> to convey here that changing the behavior to a (numb AS varchar) one,
> practically speaking, is more benign/useful (vs now), even if that is
> only a non-spe
Dean Gibson (DB Administrator) wrote:
Then I don't understand. While I've never used MySQL, the MySQL web
pages apparently indicate that VARCHAR has been supported since version
3.2: http://dev.mysql.com/doc/refman/4.1/en/char.html
Only in DDL and not the cast function, apparently. Mysq
On 2008-02-12 19:39, Ken Johanson wrote:
Dean Gibson (DB Administrator) wrote:
On 2008-02-12 16:17, Ken Johanson wrote:
Dean Gibson (DB Administrator) wrote:
...
I'm guessing you declare an explicit length of 1 (for portability),
or do you "CAST (x as char)"? And one might ask in what context
Dean Gibson (DB Administrator) wrote:
On 2008-02-12 16:17, Ken Johanson wrote:
Dean Gibson (DB Administrator) wrote:
...
I'm guessing you declare an explicit length of 1 (for portability), or
do you "CAST (x as char)"? And one might ask in what context we'd need
CHAR(1) on a numeric type, or
On 2008-02-12 16:17, Ken Johanson wrote:
Dean Gibson (DB Administrator) wrote:
...
I'm guessing you declare an explicit length of 1 (for portability), or
do you "CAST (x as char)"? And one might ask in what context we'd need
CHAR(1) on a numeric type, or else if substr/ing or left() make the
Tom Lane wrote:
Simply that a commonly used database (my) does not support it.
They do support char(n) in this context, which would have the advantage
of being standards compliant as well as de-facto portable.
Hmm, interesting. Mysql actual returns:
select cast(123 AS char(10)) -> '123' (
Ken Johanson <[EMAIL PROTECTED]> writes:
>>> What is wrong with using VARCHAR for your
>>> purpose
> Simply that a commonly used database (my) does not support it.
They do support char(n) in this context, which would have the advantage
of being standards compliant as w
Dean Gibson (DB Administrator) wrote:
> On 2008-02-12 07:30, Ken Johanson wrote:
>>>
>>> Sure, but you're a prime candidate for understanding the value of
>>> following the spec if you're trying to write software that works with
>>> multiple databases.
>>
>> The spec has diminished in this (CAST w
On 2008-02-12 07:30, Ken Johanson wrote:
Sure, but you're a prime candidate for understanding the value of
following the spec if you're trying to write software that works with
multiple databases.
The spec has diminished in this (CAST without length) context:
a) following it produces an outp
Gregory Stark wrote:
"Ken Johanson" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
SQL92 section 6.1 quoth
::=
CHARACTER []
| CHAR []
...
4) If is omitted, then a of 1 is implicit.
Therefore, writing just "char" is defined
"Ken Johanson" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>
>> SQL92 section 6.1 quoth
>>
>> ::=
>> CHARACTER []
>> | CHAR []
>>
>> ...
>>
>> 4) If is omitted, then a of 1 is implicit.
>>
>> Therefore, writing just "char" is d
On Mon, Feb 11, 2008 at 10:36:49PM -0700, Ken Johanson wrote:
> For sake of interoperability (and using an API that requires String-type
> hashtable keys), I'm trying to find a single CAST (int -> var/char)
> syntax that works between the most databases. Only char seems to be a
> candidate, but
Tom Lane wrote:
SQL92 section 6.1 quoth
::=
CHARACTER []
| CHAR []
...
4) If is omitted, then a of 1 is implicit.
Therefore, writing just "char" is defined as equivalent to "char(1)".
However when length is not defined I
Ken Johanson <[EMAIL PROTECTED]> writes:
> For sake of interoperability (and using an API that requires String-type
> hashtable keys), I'm trying to find a single CAST (int -> var/char)
> syntax that works between the most databases. Only char seems to be a
> candidate, but in 8.3 casting from a
For sake of interoperability (and using an API that requires String-type
hashtable keys), I'm trying to find a single CAST (int -> var/char)
syntax that works between the most databases. Only char seems to be a
candidate, but in 8.3 casting from an integer outputs only the first char...
Is thi
29 matches
Mail list logo
