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:
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 if the
Stephan Szabo [EMAIL PROTECTED] writes:
On Tue, 12 Feb 2008, Tom Lane wrote:
Also, section 6.10 cast specification 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
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 cast specification 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
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 error if
[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)
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-spec
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
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
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;
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 to change
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
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
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 alternative
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
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 in
Ken Johanson [EMAIL PROTECTED] writes:
Tom Lane wrote:
SQL92 section 6.1 data type quoth
character string type ::=
CHARACTER [ left paren length right paren ]
| CHAR [ left paren length right paren ]
...
4) If length is omitted,
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 well as
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.
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
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
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 without length)
Gregory Stark wrote:
Ken Johanson [EMAIL PROTECTED] writes:
Tom Lane wrote:
SQL92 section 6.1 data type quoth
character string type ::=
CHARACTER [ left paren length right paren ]
| CHAR [ left paren length right paren ]
...
4) If
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 an
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
Tom Lane wrote:
SQL92 section 6.1 data type quoth
character string type ::=
CHARACTER [ left paren length right paren ]
| CHAR [ left paren length right paren ]
...
4) If length is omitted, then a length of 1 is implicit.
Therefore,
29 matches
Mail list logo
