Hi All,
I'm using Postgresql v7.3.3. I have a small question ...
Why is that there is a maximum limit of 32 input parameters to thePostgresql function? Whereas stored procedures in Oracle and SQL Servertake more than 32 input arguments. So this puts extra burden on themiddleware dev
On Sunday 13 July 2003 17:32, Jo wrote:
> These are my PostgreSQL tables:
>
> pid | name
> 1 | A
> 2 | B
> 3 | C
> 4 | D
> 5 | E
>
> tid | pid 1 | pid 2 | pid 3
> 1 | 1| 2| 3
>
> Bascially, I would like to write a query to list only
> the names which their "pid" match th
On Monday 21 July 2003 11:29, vijaykumar M wrote:
> Hi All,
>
> I'm using Postgresql v7.3.3. I have a small question ...
>
> Why is that there is a maximum limit of 32 input parameters to the
> Postgresql function?
> Whereas stored procedures in Oracle and SQL Server
> take more than
I need to create a set for use in a query that includes all dates between a
start and ending date. Is this something I can do with a simple sql
statement or do I need to make a function for this?
---(end of broadcast)---
TIP 4: Don't 'kill -9' the
> The reason why it's not bigger is that there hasn't been enough people saying
> "I need more parameters".
That and a general speed penalty to all users of all functions.
Make (whatever) the limitation is affect only those using a large number
of parameters and you will find the limit set to a
Hi,
I'm using Postgresqlv7.3.3.
Actually my requirement was to create one temporary table and insert some values on it and finally return the inserted values.
For this simple thing i'm struggling a lot with two errors. one is 'RELATION '' ALREADY EXISTS' -- This is happening when ever i ca
Stephan Szabo wrote:
> On 8 Jul 2003, Markus Bertheau wrote:
>
> > when you have
> > select expensive_expression(column), * from table offset 20 limit 40
> >
> > can you somehow save the cost for the first 20 calculations of
> > expensive_expression?
>
> Right now the only way I can think of that
If a compare with NaN is always false, how about rewriting it as:
result = ((arg1 < arg2) ? arg2 : arg1).
Or better yet, swap arg1 and arg2 when calling float8smaller.
Use flaost8smaller( current_min, value).
JLL
Tom Lane wrote:
>
> "Michael S. Tibbetts" <[EMAIL PROTECTED]> writes:
> > I'd expe
Jean-Luc Lachance <[EMAIL PROTECTED]> writes:
> If a compare with NaN is always false, how about rewriting it as:
> result = ((arg1 < arg2) ? arg2 : arg1).
That just changes the failure mode.
regards, tom lane
---(end of broadcast)-
Joe
Tried, but...
>> select (foo(10::int2,20::int2))[1];
>> ERROR: parser: parse error at or near "[" at character 32
I'm using the version 7.3.3
Thanks..
---
> Cristian Cappo wrote:
> > >>> select __function(10::int2, 20::int2)[1]
> > ^^^ parsing error.
> >
>
>
Gavin reported UNION faster than OR in some case when doing fts queries
two years ago at O'Reilly.
---
[EMAIL PROTECTED] wrote:
> Actually, I have used a UNION to replace OR's, the case (simpliefied to)
> something like this
Is this a TODO?
---
Tom Lane wrote:
> Jean-Luc Lachance <[EMAIL PROTECTED]> writes:
> > If a compare with NaN is always false, how about rewriting it as:
> > result = ((arg1 < arg2) ? arg2 : arg1).
>
> That just changes the
Cristian Cappo A. wrote:
Tried, but...
>> select (foo(10::int2,20::int2))[1];
>> ERROR: parser: parse error at or near "[" at character 32
I'm using the version 7.3.3
Sorry, it works on 7.4devel, so I thought it might on 7.3 as well. In
any case, this works on 7.3.3:
test=# select f1[1] fro
Even better for quickly reinitialising all tables for unit-tests might be
a command that does a "TRUNCATE ALL".
JM2Cs, Wolfgang
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail comm
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this a TODO?
It'll only take ten minutes to make it a DONE, once we figure out what
the behavior ought to be. So far I think both Stephan and I argued that
MIN/MAX ought to treat NaN as larger than all ordinary values, for
consistency with the compar
15 matches
Mail list logo
