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
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
*Happy new year,*
*
*Thiago Braga Nobre
thiagobragano...@gmail.com
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
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 confuse readline about what is on the screen,
causing unreliable line editing.
Patch attached.
regards,
andreas
Index: doc/src/sgml/ref
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
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.))
Probably due to the character
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.
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.
Yours sincerely
Grzesiek Wojdyła
--
---(end of broadcast)---
TIP 4: Don't 'kill -9' the pos
The web version of the release notes in the docs for the 7.4 branch, at
http://www.postgresql.org/docs/7.4/static/release.html
is still listing docs for the 7.4.2 version. So the 7.4.3 release notes
are not online.
Please fix -- we have a Weekly News article mentioning the 7.4.3 release
and tha
18 matches
Mail list logo
