"Plotnikov Y" ...
> Подозрительно однако молчат DY&HV ;))
У тебя хороший слух :)
--
Хорсун Влад
Plotnikov Y wrote:
Подозрительно однако молчат DY&HV ;))
Ты бы луччи радовался що я молчууу...
--
Regards. Ded.
"Alexandr Kochmin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
>
> Предлагается обсудить такую штуку.
> Сделать способ получения внутри процедуры списка полей, которые из нее
> запросили.
Нужен алгоритм построения дерева зависимостей операторов и выходных параметров.
Нравится мысль.
Уже вижу, где можно использовать такую фичу.
Хотя, имхо - рюшечка, и приоритет у ней соответствующий.
Во-во,
Можно угадаю слеующий реквест:
В процедуре узнать WHERE условия, которые на неё наложены. :-)
PS. Хотя при определённом "дизайне" данная фича смотрелась бы ничего.
М
On Sun, 04 Mar 2007 09:56:30 +0300, Kovalenko Dmitry <[EMAIL PROTECTED]> wrote:
> Кстати мысль. Нафуя список - нужно к OUT-параметрам прикрутить
> свойство типа RealRequired.
Нравится мысль.
Уже вижу, где можно использовать такую фичу.
Хотя, имхо - рюшечка, и приоритет у ней соответствующий.
-
KD> Кстати мысль. Нафуя список - нужно к OUT-параметрам прикрутить
KD> свойство типа RealRequired. А в хранимке пишем
KD>
KD> if(MyVeryLargeOutParameter.RealRequired)then
KD> begin
KD> //вычисляем.
KD> end
да, точно. Так оно лучше. Я до этого не додумался.
KD> PS. Перечитал сообщение... в голо
> > Чего только не надумают.
> > Ну перечитай еще раз первый топик. Я же совсем не то писал. ;)
>
> Я о том, что с ростом числа параметров, и их зависимостей друг от друга,
> смысл подобной ручной оптимизации быстро теряется.
Тупишь. При чем тут зависимости?
Список OUT-параметров, которые реальн
Alexandr Kochmin пишет:
да нет ничего такого.
Чего только не надумают.
Ну перечитай еще раз первый топик. Я же совсем не то писал. ;)
Я о том, что с ростом числа параметров, и их зависимостей друг от друга,
смысл подобной ручной оптимизации быстро теряется.
T> Я имел в виду, что головная вызывает ещё 30 процедур.
T> И востребованность их параметров зависит от логики и востребованности
T> параметров головной процедуры.
T>
T> Главное, что при расте количества параметров число их сочетаний растёт
T> довольно быстро. И смысл ручного кодирования быстро о
Kovalenko Dmitry пишет:
А теперь представь, что параметров в головной процедуре у тебя 18 и она
вызывает ещё 30, а те...
Ты не догнал его мысль.
Вторая процедура (у которой 30 параметров) ничего не будет знать про
18 параметров головной. Ибо зачем?
Я имел в виду, что головная вызывает ещё 30
D>
D> Процедура - это "черный ящик" для сервера. Вряд ли тебя поддержат.
блин... Я ж не заставляю сервер лезти в процедуру.
Пусть он мне просто список полей даст. Дальше я уже сам.
--
С уважением
Кочмин Александр
Firebird Foundation associate member #257
KD>
KD>> А теперь представь, что параметров в головной процедуре у тебя 18 и
KD>> она вызывает ещё 30, а те...
KD>
KD> Ты не догнал его мысль.
KD>
KD> Вторая процедура (у которой 30 параметров) ничего не будет знать про
KD> 18 параметров головной. Ибо зачем?
KD>
KD> Она (вложенная) будет вычислят
> А теперь представь, что параметров в головной процедуре у тебя 18 и она
> вызывает ещё 30, а те...
Ты не догнал его мысль.
Вторая процедура (у которой 30 параметров) ничего не будет знать про
18 параметров головной. Ибо зачем?
Она (вложенная) будет вычислять только то, что попросит головная.
Процедура - это "черный ящик" для сервера. Вряд ли тебя поддержат.
Подумай о простом объединении с процедуры в запросе и планах. Намного
полезнее.
Дмитрий
ну так если в сервере сделать поддержку, то будет проще перечислять.
Но ленивые вычисления автоматом - это слишком. Мне и if написать не тяжело.
А теперь представь, что параметров в головной процедуре у тебя 18 и она
вызывает ещё 30, а те...
Короче, по моему, фича может пригодиться только для
T>
T> Ведь у тебя может вызываться процедура из процедуры, а та из
T> процедуры... И если пользователь, вызывая процедуру верхнего кажет
T> только 1 параметр, ты не задолбаешься все варианты в процедурах ручками
T> учитывать? ;-)
T>
T> Может сразу ленивые вычисления реализовать?
T> Как в хаскеле?
Ведь у тебя может вызываться процедура из процедуры, а та из процедуры...
И если пользователь, вызывая процедуру верхнего кажет только 1 параметр,
ты не задолбаешься все варианты в процедурах ручками учитывать? ;-)
Может сразу ленивые вычисления реализовать?
Как в хаскеле? ;-)
> Предлагается обсудить такую штуку.
> Сделать способ получения внутри процедуры списка полей, которые из нее
> запросили.
> Для чего: да чтоб в процедуре видеть, что некая выходная переменная нне нужна
> вызвавшему, и соответвенно ее не вычислять.
> Сейчас можно сделать с помощью дополнительно
AC>
AC> Привет, Alexandr!
AC> Вы пишешь к All 03 марта 2007:
AC>
AC> [Sorry, skipped]
AK>> в чем достоинства: ненадо изменять количество входных параметров,
AK>> ненадо где-то формировать p_list, ненадо вызывать функцию pos,
AK>> механизм универсальный.
AC>
AC> Ещё один у
Привет, Alexandr!
Вы пишешь к All 03 марта 2007:
[Sorry, skipped]
AK> в чем достоинства: ненадо изменять количество входных параметров,
AK> ненадо где-то формировать p_list, ненадо вызывать функцию pos,
AK> механизм универсальный.
Ещё один универсальный решатель за
Предлагается обсудить такую штуку.
Сделать способ получения внутри процедуры списка полей, которые из нее
запросили.
Для чего: да чтоб в процедуре видеть, что некая выходная переменная нне нужна
вызвавшему, и соответвенно ее не вычислять.
Пример
есть процедура
CREATE PROCEDURE NEW_PROCEDURE
ret
21 matches
Mail list logo
