Excerpts from Maciej Sakrejda's message of mar ene 11 03:28:13 -0300 2011:
Tried asking this in pgsql-general but I got no response, so I thought
I'd give hackers a shot:
postgres=# select (((1.7976931348623157081e+308)::double
precision)::text)::double precision;
ERROR:
Tried asking this in pgsql-general but I got no response, so I thought
I'd give hackers a shot:
postgres=# select (((1.7976931348623157081e+308)::double
precision)::text)::double precision;
ERROR: 1.79769313486232e+308 is out of range for type double precision
I'm working on a pg driver and in
On Wed, Aug 09, 2006 at 12:21:40PM +0100, stark wrote:
I think the ideal combination is having every type have precisely one implicit
cast up the type tree and assignment casts down the tree. I don't see us
every needing anything more complex than a flat tree of a single base type
for each
Martijn van Oosterhout kleptog@svana.org writes:
You're not required to provide all the casts, but it's user friendly to
do so. Requiring double casts to go between two essentially compatable
types seems silly...
I believe what Greg had in mind included the idea that the parser would
stark [EMAIL PROTECTED] writes:
I think the ideal combination is having every type have precisely one
implicit cast up the type tree and assignment casts down the
tree.
No, because for example in the case of the numeric datatypes, that would
result in *every* cross-type operation being done in
Tom Lane [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
stark [EMAIL PROTECTED] writes:
It seems odd to me that implicit casts are checked for when you call a
function but not when you're implicitly calling a function via a cast. As a
result there are a *lot* of redundant
It seems odd to me that implicit casts are checked for when you call a
function but not when you're implicitly calling a function via a cast. As a
result there are a *lot* of redundant casts in our catalog, essentially n!
casts for a domain with n types in it. So for example there are 138 casts
stark [EMAIL PROTECTED] writes:
It seems odd to me that implicit casts are checked for when you call a
function but not when you're implicitly calling a function via a cast. As a
result there are a *lot* of redundant casts in our catalog, essentially n!
casts for a domain with n types in it.
Tom Lane wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
Tom Lane wrote:
Yes, it can cast to varchar, but that doesn't help because there are no
varchar operators ;-). To resolve the operator, it has to promote both
sides to text, and you didn't offer a cast to text.
I don't get
Shachar Shemesh [EMAIL PROTECTED] writes:
What I don't understand is this. The cast from varchar to text is a
no-function one. I.e. - they are defined to be memory-represented the
same. If that is the case, one would expect them to also share the input
and ouput functions. When looking at
Tom Lane wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
I have defined a datatype called varcharci, shamelessly yanking the
input, output, recv and send functions from varchar. This means (as far
as I understand things) that this type is binary compatible with varchar.
Use text, not
Shachar Shemesh [EMAIL PROTECTED] writes:
Tom Lane wrote:
Yes, it can cast to varchar, but that doesn't help because there are no
varchar operators ;-). To resolve the operator, it has to promote both
sides to text, and you didn't offer a cast to text.
I don't get it.
When we look to see
Shachar Shemesh [EMAIL PROTECTED] writes:
I have defined a datatype called varcharci, shamelessly yanking the
input, output, recv and send functions from varchar. This means (as far
as I understand things) that this type is binary compatible with varchar.
Use text, not varchar.
Why is
Hi all,
I have defined a datatype called varcharci, shamelessly yanking the
input, output, recv and send functions from varchar. This means (as far
as I understand things) that this type is binary compatible with varchar.
As such, I used the following two lines:
create cast ( varcharci AS
14 matches
Mail list logo
