Re: Bug

Поиск
Список
Период
Сортировка
От Thiago Braga Nobre
Тема Re: Bug
Дата
Msg-id CAH3KbcUdzD8D=asd7+yGO3MdqwQ-jnww6o-uMHkV_sVGqGquHg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Bug  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-docs
Дерево обсуждения
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 systems and these are aperfect pasta, sometimes a seemingly simple change could destabilize the entire system.

Another thing I find bad is that in PostgreSQL to perform a selectof all records and it does not allow the order by only one column.

Thanks for the support and attention 

2012/1/27 Robert Haas <robertmhaas@gmail.com>
On Tue, Jan 3, 2012 at 7:40 PM, Thiago Braga Nobre
<thiagobraganobre@gmail.com> 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 conversion from string to integer?

Eh... maybe the other way around?

It has long bothered me that, beginning in 8.3, we can't figure out
that substring(123456, 2, 2) isn't intended to cast 123456 to text.
There just aren't that many other sensible things for that to mean.
It's not exactly clear what to do about it, though, since as far as
the backend knows we could have intended to call substring(bit,
integer, integer) or substring(bytea, integer, integer) rather than
substring(text, integer, integer).  How do we make a principled
decision to prefer text?  I don't know, but I wish we had a way.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



--
Atenciosamente,

Thiago Braga Nobre
(21) 8527-9400

В списке pgsql-docs по дате отправления: