Обсуждение: when does a function name get mapped to an OID?

If this is answered in the docs I apologize, I've been looking around
without much success.

I am trying to bring order to our schema loading process.  We have about
a dozen files with functions, triggers and views defined in them and
some of them depend on functions declared on other files, etc...so in
the past we've had situations where we unload and reload one of the
files and that breaks something that was depending on the contents of
the reloaded file (i.e. fmgr_info: 12343567 cache lookup failed
messages).  So, I'm making a bit more of a sane system to make sure
things get loaded and reloaded in the right order.

I was noticing that within one of the files, something like this is
declared:

drop function bar();
drop function foo();
create function foo() returns int4 as '
    select bar();
' language 'sql';
create function bar() returns int4 as '
   select 1234;
' language 'sql';

This loads into the db just fine.  Which got me to thinking, shouldn't
the loading of foo() throw an error since at that time bar() does not
exist?  So my best guess is that function names don't get mapped to OIDs
until first actual use.  Is this correct?  It would save me trouble if
so since I wouldn't have to worry about the order in which they are
loaded so much as to ensure that if anything is REloaded, that any
dependencies are also reloaded.

Thanks,
Fran

On Tue, 23 Apr 2002, Fran Fabrizio wrote:

>
> If this is answered in the docs I apologize, I've been looking around
> without much success.
>
> I am trying to bring order to our schema loading process.  We have about
> a dozen files with functions, triggers and views defined in them and
> some of them depend on functions declared on other files, etc...so in
> the past we've had situations where we unload and reload one of the
> files and that breaks something that was depending on the contents of
> the reloaded file (i.e. fmgr_info: 12343567 cache lookup failed
> messages).  So, I'm making a bit more of a sane system to make sure
> things get loaded and reloaded in the right order.
>
> I was noticing that within one of the files, something like this is
> declared:
>
> drop function bar();
> drop function foo();
> create function foo() returns int4 as '
>     select bar();
> ' language 'sql';
> create function bar() returns int4 as '
>    select 1234;
> ' language 'sql';
>
> This loads into the db just fine.  Which got me to thinking, shouldn't
> the loading of foo() throw an error since at that time bar() does not
> exist?

This will throw an error if you try and run foo() before you create bar().
But from my experience the function is compiled when it is first run a
plan created. It is not compiled at creation time.


> So my best guess is that function names don't get mapped to OIDs
> until first actual use.  Is this correct?  It would save me trouble if
> so since I wouldn't have to worry about the order in which they are
> loaded so much as to ensure that if anything is REloaded, that any
> dependencies are also reloaded.
>
> Thanks,
> Fran
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: 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
>

HTH

Darren Ferguson

Fran Fabrizio <ffabrizio@mmrd.com> writes:
> I was noticing that within one of the files, something like this is
> declared:

> drop function bar();
> drop function foo();
> create function foo() returns int4 as '
>     select bar();
> ' language 'sql';
> create function bar() returns int4 as '
>    select 1234;
> ' language 'sql';

> This loads into the db just fine.

It does?

regression=# create function foo() returns int4 as '
regression'#     select bar();
regression'# ' language 'sql';
ERROR:  Function 'bar()' does not exist
        Unable to identify a function that satisfies the given argument types
        You may need to add explicit typecasts

The SQL language differs from the other ones in that it tries to
syntax-check the function body at CREATE time.  Perhaps this
inconsistency is not good, but that's how it's been for a long time.
You *can* get away with the above practice in the PL languages.

            regards, tom lane

Hi everybody

Could someone please tell me from which Version on the type bytea was
supported in PostgreSQL?

Thank you
Conni

Cornelia Boenigk wrote:
> Hi everybody
>
> Could someone please tell me from which Version on the type bytea was
> supported in PostgreSQL?

    I  can  see it in Postgres v4.2 (the original non-SQL version
    released by UCB). So it  is  supported  in  ALL  versions  of
    PostgreSQL. Why do you ask?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

I should say what I mean and mean what I say.  :-)  In an effort for
brevity, my example included the simplest functions I could think of off
the top of my head.  In reality, they are large PL/PgSQL beasties.  Good
to know that it won't work for plain ole SQL functions, though...we've
got some of those too.  Thus, I'll have to enforce the loading order
after all.  Thanks for the info Tom.

-Fran

>>drop function bar();
>>drop function foo();
>>create function foo() returns int4 as '
>>    select bar();
>>' language 'sql';
>>create function bar() returns int4 as '
>>   select 1234;
>>' language 'sql';
>
>
>>This loads into the db just fine.
>
>
> It does?