In this case if the function takes the string parameter, whatever the value
provided, but it should be converted to string using aconversion, ie,
substring (123456, 2, 2), would be converted tosubstring ("123456" 2, 2),
the postgreSQL hospital should make this process as we work often with
legacy s
On Tue, Jan 3, 2012 at 7:40 PM, Thiago Braga Nobre
wrote:
> A practical example is the scheme substring (text, integer, integer), if
> I step substring (row ['name'], start, end) but for some reason they start
> and end string causes an exception, thesubstring function should not perform
> the con
what is the typing table field? If the type is numeric you convert to
number, if the type is varchar to string, it is very obvious, is not it?
2012/1/3 Scott Marlowe
> No it was broken before, because you didn't know if what you were
> comparing was what it meant. for instance:
>
> where numbe
A practical example is the scheme substring (text, integer, integer), if I
step substring (row ['name'], start, end) but for some reason they start
and end string causes an exception, thesubstring function should not perform
the conversion from string to integer?
thanks a lot
2012/1/3 Scott Marl
But if one is a numeric and one is a text, which do you convert?
There's lots of conversations on this in the lists from about 4 or 5
years ago. Since converting one way or the other can cause two
different outputs, you can't be sure which is the right way. If you
need a field cast, you now have
was better before, thanks and happy 2012
2012/1/3 Scott Marlowe
> It was considered a bug when things were automagically cast before,
> it's considered fixed now. What's your query and table defs look
> like?
>
> On Tue, Jan 3, 2012 at 2:57 PM, Thiago Braga Nobre
> wrote:
> > that's right
> >
No it was broken before, because you didn't know if what you were
comparing was what it meant. for instance:
where number='01000';
should we cast the number to text, or the text to numeric?
On Tue, Jan 3, 2012 at 3:44 PM, Thiago Braga Nobre
wrote:
> was better before, thanks and happy 2012
>
>
It was considered a bug when things were automagically cast before,
it's considered fixed now. What's your query and table defs look
like?
On Tue, Jan 3, 2012 at 2:57 PM, Thiago Braga Nobre
wrote:
> that's right
>
>
> 2012/1/3 Scott Marlowe
>>
>> On Tue, Jan 3, 2012 at 9:47 AM, Thiago Braga Nob
that's right
2012/1/3 Scott Marlowe
> On Tue, Jan 3, 2012 at 9:47 AM, Thiago Braga Nobre
> wrote:
> > Hi
> > why in version 8.4.4 I have to do is cast in the previous version of PHP
> > itself postgres already identified this conversion?
> > thank you
>
> Are you referring to the absence of au
On Tue, Jan 3, 2012 at 9:47 AM, Thiago Braga Nobre
wrote:
> Hi
> why in version 8.4.4 I have to do is cast in the previous version of PHP
> itself postgres already identified this conversion?
> thank you
Are you referring to the absence of automatic type conversion on
postgresql that started with
Patch applied. Thanks.
---
Andreas Seltenreich wrote:
> While testing the texinfo target, I noticed the following bug in the
> psql reference. Declaring a printed character as part of the control
> sequence is likely to c
Rainer Brandt wrote:
> Hi,
>
> All places that mention the trigger event info hash pointer $_TD
> end with the "->" characters. The hash keys are omitted.
> That is certainly not what you wanted.
> (Also, the code examples will not compile under Perl. (I didn't
> try, but can see that they won't
Grzegorz Wojdyla <[EMAIL PROTECTED]> writes:
> Hi. There is a mistake in above place - in the table 9-3 (Bit String Bitwise
> Operators). In row number 3 the result is 0 and probably should be 11100.
It seems already fixed in 8.0 docs, but I have corrected the 7.4 branch
as well. Thanks.
13 matches
Mail list logo
