SEO

Hello

I propose two kinds of functions:

a) generic functions - this function allows any params without any
implicit casting (it can implemented only in C language). This
function have to have specified return type. It usable for constructor
function and for some other. It allows unspecified number of params
without parser changes. There are not limits for params (only max
number) and there are not any implicit casting. Any parameter can take
additional tag with AS keyword.

Limits: only one function with specified name can exists in schema.

Sample:

CREATE FUNCTION format(any)
RETURNS text LANGUAGE C ....;

SELECT format(1, 'aaa' AS b, ARRAY[1,2,3]) -> '(1, b:"aaa",[1,2,3])'

generic function can be well used for constructor function

b) constructor function - this function returns typed composite or
array value. It's in conformance with ANSI SQL. Constructor function
is any generic function where name is same like any composite type or
domain. Behave of constructor is same for all types.

Sample:
CREATE TYPE ftype AS (a integer, b integer);

SELECT ftype(), ftype(10), ftype(10,20); ->
(NULL, NULL), (10,NULL), (10,20) ~ (10,20)::ftype

CREATE DOMAIN fdom AS int[];

SELECT fdom(), fdom(10,20,30); ->
'{}','{10,20,30}'; ~ it's eq ARRAY[10,20,30]::int[];

Why constructors?

Composite values are referenced in SQL/PSM. When I wont to fill
composite variables directly, I have to call constructor before:

DECLARE v mytype;
SET v = mytype();
SET v.f = 10; ~ or shortly SET v = mytype(10);

Any comments are welcome

Regards
Pavel Stehule

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> I propose two kinds of functions:

> a) generic functions - this function allows any params without any
> implicit casting (it can implemented only in C language).

Can't you do that already with ANYELEMENT, or at the worst ANY?

> It allows unspecified number of params
> without parser changes.

Why is that a good idea (and if you think it won't take parser changes,
you're wrong)?

> Limits: only one function with specified name can exists in schema.

This is why it's a bad idea. Please note that the unique index on
pg_proc cannot enforce that, even if we wanted such a restriction.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On 18/01/2008, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
> > I propose two kinds of functions:
>
> > a) generic functions - this function allows any params without any
> > implicit casting (it can implemented only in C language).
>
> Can't you do that already with ANYELEMENT, or at the worst ANY?

Anyelement is related with casting to common type.

postgres=# create or replace function fx(anyelement, anyelement)
returns text as $$begin return 'ahoj'; end; $$ language plpgsql;
CREATE FUNCTION
postgres=# select fx(1,'a');
ERROR: invalid input syntax for integer: "a"
postgres=# select fx(1,'a');

I would to have independent parameters and move type checking to
function. Then I don't need register function exactly and then I can
have different numbers of arguments. It's similar like C varargs
functions so now I cannot effectively implement printf function,
because all parameters are casted to varchar.

Using any is broken. ?
postgres=# create or replace function fx1(any) returns text as $$begin
return 'ahoj'; end; $$ language plpgsql;
ERROR: syntax error at or near "any"
LINE 1: create or replace function fx1(any) returns text as $$begin ...
^
>
> > It allows unspecified number of params
> > without parser changes.
>
> Why is that a good idea (and if you think it won't take parser changes,
> you're wrong)?

Of course. Implementation needs some changes in parser. But new
generic function doesn't need it. With generic functions some xml
functions could exists outside parser. And it's simple tool for
constructors.

>
> > Limits: only one function with specified name can exists in schema.
>
> This is why it's a bad idea. Please note that the unique index on
> pg_proc cannot enforce that, even if we wanted such a restriction.
>

we can use partial unique index, if it is possible - I didn't test it.

Regards
Pavel Stehule
> regards, tom lane
>

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> On 18/01/2008, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Can't you do that already with ANYELEMENT, or at the worst ANY?

> I would to have independent parameters and move type checking to
> function.

Okay, then you want ANY.

> Then I don't need register function exactly and then I can
> have different numbers of arguments.

The different-numbers-of-arguments bit is what I'm objecting to.
Just register the function as foo(ANY), foo(ANY,ANY), foo(ANY,ANY,ANY),
etc, and you're done without breaking anything else.

> we can use partial unique index, if it is possible - I didn't test it.

It's not --- partial indexes on system catalogs are not supported, and
pg_proc is certainly one catalog that that restriction will never be
relaxed for. (How you going to execute a predicate without doing
function lookups?) I don't believe that the constraint could be
expressed as a partial index predicate anyway --- how will you say
that foo(...) and foo(int) conflict, but foo(int) and foo(int,int)
don't?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On 18/01/2008, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
> > On 18/01/2008, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Can't you do that already with ANYELEMENT, or at the worst ANY?
>
> > I would to have independent parameters and move type checking to
> > function.
>
> Okay, then you want ANY.
>
> > Then I don't need register function exactly and then I can
> > have different numbers of arguments.
>
> The different-numbers-of-arguments bit is what I'm objecting to.
> Just register the function as foo(ANY), foo(ANY,ANY), foo(ANY,ANY,ANY),
> etc, and you're done without breaking anything else.

It's what I unlike - but maybe. But I am not able create function with
ANY params. Is it possible do it via CREATE FUNCTION .. ?

>
> > we can use partial unique index, if it is possible - I didn't test it.
>
> It's not --- partial indexes on system catalogs are not supported, and
> pg_proc is certainly one catalog that that restriction will never be
> relaxed for. (How you going to execute a predicate without doing
> function lookups?) I don't believe that the constraint could be
> expressed as a partial index predicate anyway --- how will you say
> that foo(...) and foo(int) conflict, but foo(int) and foo(int,int)
> don't?
>

no, I spoke about constraint - there can be only one function
foo(anyparams) or any current functions. So lookup find nearest
function or find generic function.

Current implementation ensure unique params for overloaded functions
without unique index too - so I thing Its possible. It's same
mechanism.

regards
Pavel Stehule


> regards, tom lane
>

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> But I am not able create function with
> ANY params. Is it possible do it via CREATE FUNCTION .. ?

It's a reserved word :-(. Try "any"

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On 19/01/2008, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
> > But I am not able create function with
> > ANY params. Is it possible do it via CREATE FUNCTION .. ?
>
> It's a reserved word :-(. Try "any"
>
> regards, tom lane
>

I did it
postgres=# create or replace function fx1(any, any) returns text
language C strict;
ERROR: syntax error at or near "any"
LINE 1: create or replace function fx1(any, any) returns text langua...
^
postgres=#

do you have any sample, please,

thank you
Pavel

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Sat, 19 Jan 2008, Pavel Stehule wrote:

> On 19/01/2008, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>>> But I am not able create function with
>>> ANY params. Is it possible do it via CREATE FUNCTION .. ?
>>
>> It's a reserved word :-(. Try "any"
>>
>> regards, tom lane
>>
>
> I did it
> postgres=# create or replace function fx1(any, any) returns text
> language C strict;
> ERROR: syntax error at or near "any"
> LINE 1: create or replace function fx1(any, any) returns text langua...
> ^
> postgres=#
>
> do you have any sample, please,

Tom said, try "any". Don't forget about double quotes


>
> thank you
> Pavel
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>

Regards,
Oleg
__________________________________________________ ___________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

> > do you have any sample, please,
>
> Tom said, try "any". Don't forget about double quotes
>

I am blind thank you
Pavel

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Hello

>
> The different-numbers-of-arguments bit is what I'm objecting to.
> Just register the function as foo(ANY), foo(ANY,ANY), foo(ANY,ANY,ANY),
> etc, and you're done without breaking anything else.
>

I found simple solution, it uses ANY, but number of necessary ANY
arguments is generated dynamically:

FuncCandidateList
FuncnameGetCandidates(List *names, int nargs)
{
FuncCandidateList resultList = NULL;
char *schemaname;
.... /* anyparams has unlimeted pronargs, we cannot check it */

if (pronargs == 1 && procform->proargtypes.values[0]
== ANYPARAMSOID)
generic_function = true;

/* Ignore if it doesn't match requested argument count */
else if (nargs >= 0 && pronargs != nargs)
continue;

.....
/*
* Okay to add it to result list
*/

if (!generic_function)
{
newResult = (FuncCandidateList)
palloc(sizeof(struct
_FuncCandidateList) - sizeof(Oid)
+ pronargs * sizeof(Oid));
newResult->pathpos = pathpos;
newResult->oid = HeapTupleGetOid(proctup);
newResult->nargs = pronargs;
memcpy(newResult->args, procform->proargtypes.values,
pronargs * sizeof(Oid));

newResult->next = resultList;
resultList = newResult;
}
else
{
/* generic function hasn't own params, but we
know numbers and
* we can use ANY type.
*/
int i;

newResult = (FuncCandidateList)
palloc(sizeof(struct
_FuncCandidateList) - sizeof(Oid)
+ nargs * sizeof(Oid));
newResult->pathpos = pathpos;
newResult->oid = HeapTupleGetOid(proctup);
newResult->nargs = nargs;
for (i = 0; i < nargs; i++)
newResult->args[i] = ANYOID;

newResult->next = resultList;
resultList = newResult;
}

It is more simpler than I though and it works. With this technique I
don't need some mentioned restriction.

ANYPARAMS is only syntactic sugar for n x ANY

What do you thing about it, please?

Regards
Pavel Stehule




> > we can use partial unique index, if it is possible - I didn't test it.
>
> It's not --- partial indexes on system catalogs are not supported, and
> pg_proc is certainly one catalog that that restriction will never be
> relaxed for. (How you going to execute a predicate without doing
> function lookups?) I don't believe that the constraint could be
> expressed as a partial index predicate anyway --- how will you say
> that foo(...) and foo(int) conflict, but foo(int) and foo(int,int)
> don't?
>
> regards, tom lane
>

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend