am Mon, dem 14.07.2008, um 11:21:17 +0530 mailte Anoop G folgendes:
> SELECT mf,sf,(mf mf * comm /100) (sf sf * comm/100) as flt_claim;
^^^ ^^^ ^^^
That's not valid SQL.
Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (m
Hai all,
I am new to plpgsql ,I have a table structure:
Column | Type | Modifiers
+--+---
mf | double precision |
sf | double precision |
comm | integer |
I create a the following funtion
create or replace function test_perc(
Tom Lane wrote:
Most people around this project think that the best way to do that is to
push as much logic as you can into server-side stored procedures. That
gives you every advantage that a persistent-prepared-statement feature
would offer, and more besides:
It's simply to complicated to
>[snip]
> What's wrong with using complex views, stored procedures, functions and
> maybe even custom data types to accomplish what you want here?
Hi Steve,
Correct me if I’m wrong, but views can not accept parameters, and stored
procedures require defining sets of custom data types or some oth
Hello
8.4 can inline SRF SQL immutable functions. so
SELECT * FROM fce(param) should be efective like SELECT * from
wrapped_tab where col = param
Regards
Pavel Stehule
2008/7/13 daniel blanco <[EMAIL PROTECTED]>:
> Ok, i see... well. when i have to return a set of records i'll
> use
