proposal: generic function, constructor function

"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

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

"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

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

"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

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

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

do you have any sample, please,

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

I am blind thank you
Pavel

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