Hi,
Is there any function in postgre to know the size of the data in a
row of a table ?
Shavonne Marietta Wijesinghe <[EMAIL PROTECTED]> schrieb:
> I have 2 schemas "operativo" and "autore" and they both have a table "PECDT00"
>
> i want to create a function with the following sql command (using the
> programme
> pgadmin 3) in pgadmin 3 there is a small wizard to fill when u creat
I have 2 schemas "operativo" and "autore" and they both have a table "PECDT00"
i want to create a function with the following sql
command (using the programme pgadmin 3) in pgadmin 3 there is a small wizard to
fill when u create a function and u have to add the return type..
this is the
Found a solution
Second function can be written as
Get_count(anyarray, int)
Select
count(b_column) from some_table where some_field_1 any ($1) and some_field_2 =
$2;
Calling this function:
Select
Get_count(array(functio
st 16, 2005
3:39 AM
To: Akshay Mathur
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] sql function:
using set as argument
Is there a reason not to build it in as a sub-query?
E.g., if you have a function get_count( int ):
SELECT count(b_column)
FROM
some_table
Is there a reason not to build it in as a sub-query?E.g., if you have a function get_count( int ): SELECT count(b_column)FROM some_tableWHERE some_field_1 in ( SELECT a_column FROM a_table WHERE some_condition)AND some_field_2 = $2; --Thomas F. O'ConnellCo-Founder, Information ArchitectSit
Hi,
I have a function that returns a set.
Looks like:
Select
a_column from a_table where some_condition;
I want to use output of this function as an argument of
another function
Second
looks like:
Get_count(result_set_of_function_
On Wednesday 15 October 2003 22:46, Zhao, Scott wrote:
> Hi All,
>
> Is there a function available to validate if the input is a correct
> money format? For exapmle, "23.56" is a correct number but "23.567" is
> incorrect. I just like to do this in postgres level not in my
> application code.
Well
Title: Message
Hi
All,
Is there a function
available to validate if the input is a correct money format? For
exapmle, "23.56" is a correct number but "23.567" is incorrect. I just like to
do this in postgres level not in my application code.
Thanks
Scott
Robert Treat <[EMAIL PROTECTED]> writes:
> ... I still
> would like to see answered is whether oracle or others support >$ as an
> operator, or if the sql spec has anything to say on the matter.
The SQL spec does not have the concept of user-definable operators at
all, so it provides no useful gu
On Fri, 2003-01-10 at 04:13, Radu-Adrian Popescu wrote:
>
> Robert, my dear fellow...
>
> How about checking your facts before contradicting anyone ? Shame on you !
> Have you actually tried to do a SELECT* from foo ? Pathetic !
At least you started out all nice and flowery...
> Try it out, if
obert Treat" <[EMAIL PROTECTED]>
To: "Radu-Adrian Popescu" <[EMAIL PROTECTED]>
Cc: "Achilleus Mantzios" <[EMAIL PROTECTED]>; "Tom Lane"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, January 09, 2003 10:44 PM
Subject: Re: [SQL]
On Thu, 2003-01-09 at 11:29, Radu-Adrian Popescu wrote:
> What i'm saying is that i know that some of my colleagues, nice guys for
> that matter, and good programmers, will come screaming
> to me "what's with the b.s. error ?!?", and when i'll tell them that the sql
> parser belives that's an inexi
Nice to see that things are starting to move.
I was wandering however whether I've succeeded in making a point.
Regards,
=
Radu-Adrian Popescu
CSA, DBA, Developer
Aldratech Ltd.
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
Subject: Re: [SQL] SQL
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Although the rules could be similar to those for + and - at the end of
> operator strings (no $ at the end of an operator unless it contains
> characters not normally in SQL92 operators). I'm not sure that
> behavior is sensible either, but if someone wa
On Thu, 9 Jan 2003, Tom Lane wrote:
> Achilleus Mantzios <[EMAIL PROTECTED]> writes:
> > On Thu, 9 Jan 2003, Radu-Adrian Popescu wrote:
> >> Why is that ? Because the >$ does not exist, not in the default operator
> >> list
>
> > i think the parser is built with yacc, (not "from scratch code") so
ELECT * is the same as SELECT
*.
I rest my case.
Cheers,
=
Radu-Adrian Popescu
CSA, DBA, Developer
Aldratech Ltd.
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Achilleus Mantzios" <[EMAIL PROTECTED]>
Cc: "Radu-Adrian Popescu" <
Achilleus Mantzios <[EMAIL PROTECTED]> writes:
> On Thu, 9 Jan 2003, Radu-Adrian Popescu wrote:
>> Why is that ? Because the >$ does not exist, not in the default operator
>> list
> i think the parser is built with yacc, (not "from scratch code") so
> maybe finding if ">$" is in the specific DB's
On Thu, 9 Jan 2003, Radu-Adrian Popescu wrote:
> Since you can overload and define new operators, the parser must - at some
> point in time - lookup the operator definition.
> It seems to me (but this is just an ideea), that the rules should go like
> this :
> ...
> check >$ is a defined operator
Mantzios" <[EMAIL PROTECTED]>
To: "Radu-Adrian Popescu" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, January 09, 2003 9:29 PM
Subject: Re: [SQL] SQL function parse error ?
On Thu, 9 Jan 2003, Radu-Adrian Popescu wrote:
>
>
> Why is that ? B
<[EMAIL PROTECTED]>
To: "Radu-Adrian Popescu" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, January 09, 2003 4:48 PM
Subject: Re: [SQL] SQL function parse error ?
"Radu-Adrian Popescu" <[EMAIL PROTECTED]> writes:
> This is SQL, and pe
On Thu, 9 Jan 2003, Radu-Adrian Popescu wrote:
>
>
> Why is that ? Because the >$ does not exist, not in the default operator
> list (also there is no operator defined
> using $ anywhere within). And because whitespacing the code solves the
> problem, which is rather thin, i must say.
>
Radu-Adri
p clear this issue.
Cheers,
=
Radu-Adrian Popescu
CSA, DBA, Developer
Aldratech Ltd.
- Original Message -
From: "Tomasz Myrta" <[EMAIL PROTECTED]>
To: "Radu-Adrian Popescu" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, January 09, 2003 3:22
"Radu-Adrian Popescu" <[EMAIL PROTECTED]> writes:
> This is SQL, and people who are using PostgreSql write SQL, not
> whitespace-sensitive SQL, bash or whatever.
Nonsense. SQL syntax is space-sensitive. Or have you successfully
written
SELECTXFROMY;
lately?
There has occasionally been t
Radu-Adrian Popescu wrote:
I'm perfectly aware of the fact that a space solves the issue here.
What I'm saying is that it is not natural nor common to take some
whitespace
into
account when parsing, since this is not bash language, nor python, as it
shouldn't be !
This is SQL, and people who ar
<[EMAIL PROTECTED]>
To: "Radu-Adrian Popescu" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, January 09, 2003 1:56 PM
Subject: Re: [SQL] SQL function parse error ?
Radu-Adrian Popescu wrote:
>
> Take the following for example:
> create or replace f
Radu-Adrian Popescu wrote:
Take the following for example:
create or replace function testfunc1(int) returns setof test as
'
select * from test where age>$1;
'^^
language sql;
I didn't find it in documentation, but sql functions are like bash (you
forgot ab
Hello !
There is a strange behaviour in the SQL function
parser (haven't tested this with the plpgsql lang) when using standard
operators
and function parameters.
Take the following for example:
create or replace function
testfunc1(int) returns setof test as' select * from
test where
Brian Blaha wrote:
>
> I would like to write a function as a set of SQL statements, and then
> use that function
> in a trigger. However, since triggers require a return type of opaque,
> and SQL functions
> cannot return type opaque, this doesn't look possible. Am I missing
> something? The SQL
Brian Blaha <[EMAIL PROTECTED]> writes:
> I would like to write a function as a set of SQL statements, and then
> use that function
> in a trigger. However, since triggers require a return type of opaque,
> and SQL functions
> cannot return type opaque, this doesn't look possible.
You could cal
I would like to write a function as a set of SQL statements, and then
use that function
in a trigger. However, since triggers require a return type of opaque,
and SQL functions
cannot return type opaque, this doesn't look possible. Am I missing
something? The SQL
that I would expect to do this
Sue Humphrey <[EMAIL PROTECTED]> writes:
> I would like examples of functions using update, insert and
> delete, where LANGUAGE 'SQL', both how to write them and how to
> use them.
Have you read the documentation?
http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/xfunc-sql.html
The fi
I would like examples of functions using update, insert and
delete, where LANGUAGE 'SQL', both how to write them and how to
use them.
I've got examples of functions as selects coming out of my ears,
and PL/pgsql examples of more complex needs, but I just need to
run a simple UPDATE. And I forsee
Eddy,
> What value should I RETURN for a SQL FUNCTION that contains an INSERT
> statement?
OPAQUE.
-Josh
__AGLIO DATABASE SOLUTIONS___
Josh Berkus
Complete information technology [EMAIL PROTECTED]
and data management
I've just looked at the new online 7.2 documentation and found that all
functions must end in some kind of select.
How about this then?
CREATE FUNCTION foo(varchar)
RETURN unknown
AS '
INSERT INTO footable VALUES ($1);
SELECT null; '
LANGUAGE 'sql';
"Edward Grabczewski" <[EMAIL PROTE
What value should I RETURN for a SQL FUNCTION that contains an INSERT
statement?
--
Eddy Grabczewski
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Hi all,
having this simple table:
create table foo (attribute text);
and this simple function:
create function f()
returns foo
as
'
select ' 'test' '::text
'
langauge 'sql' ;
When I execute (though psql) select f();
I get the following result
f
136411800
instead of
37 matches
Mail list logo
