Jan Wieck <[EMAIL PROTECTED]> writes:
> Just successfully loading an old-style C function doesn't
> guarantee that it works anyway. I pointed out before that the
> changes due to TOAST require each function that takes
> arguments of varlen types to expect toasted val
> Bruce Momjian wrote:
> >
> > > I didn't want to do this during development, but now that there are no
> > > more old-style internal functions left, I suppose you could make a good
> > > argument that this is worth doing for old-style dynamically loaded
> > > functions. Will put it on the to-do
> > For that matter, I think past version updates haven't even forced
> > recompiles of user-defined functions, at least not ones that didn't poke
> > into system innards. We can't get away with requiring a source code
> > change --- people will scream about it.
>
> imho that is *not* sufficient
Bruce Momjian wrote:
>
> > I didn't want to do this during development, but now that there are no
> > more old-style internal functions left, I suppose you could make a good
> > argument that this is worth doing for old-style dynamically loaded
> > functions. Will put it on the to-do list.
> >
>
> For that matter, I think past version updates haven't even forced
> recompiles of user-defined functions, at least not ones that didn't poke
> into system innards. We can't get away with requiring a source code
> change --- people will scream about it.
imho that is *not* sufficient to keep fro
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I would support a single symbol to mark the entire object file. In
> fact, I would require old-style functions to add a symbol, and have
> new-style functions left alone.
That won't fly.
> There are not that many functions out there, are there? Peopl
> I didn't want to do this during development, but now that there are no
> more old-style internal functions left, I suppose you could make a good
> argument that this is worth doing for old-style dynamically loaded
> functions. Will put it on the to-do list.
>
> Are people satisfied with the no
> > Just successfully loading an old-style C function doesn't
> > guarantee that it works anyway. I pointed out before that the
> > changes due to TOAST require each function that takes
> > arguments of varlen types to expect toasted values.
>
> Couldn't the functi
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Couldn't the function handler detoast the values before handing them to
> the function? That would be slower, but it would allow people to continue
> to use the "simpler" interface.
This would be a moderately expensive thing to do --- not impossible
Jan Wieck writes:
> Just successfully loading an old-style C function doesn't
> guarantee that it works anyway. I pointed out before that the
> changes due to TOAST require each function that takes
> arguments of varlen types to expect toasted values.
Couldn't the
> > More to the point, I think we have to assume old-style interface if we
> > see ... LANGUAGE 'C' with no other decoration, because any other
> > assumption is guaranteed to break all existing user-defined functions.
>
> Just successfully loading an old-style C function doesn't
> g
Tom Lane wrote:
>
> More to the point, I think we have to assume old-style interface if we
> see ... LANGUAGE 'C' with no other decoration, because any other
> assumption is guaranteed to break all existing user-defined functions.
Just successfully loading an old-style C function doesn't
mlw <[EMAIL PROTECTED]> writes:
> I'm not sure what "NewC" is, nor do I understand what problem it is
> attempting to fix.
I haven't gotten around to updating the main documentation yet (my bad)
but the design document about the fmgr rewrite is in current sources
as src/backend/utils/fmgr/README
'Marko Kreen' wrote:
>
> On Wed, Nov 15, 2000 at 02:42:24PM +0100, Zeugswetter Andreas SB wrote:
> >
> > > > We need the 7.0 style for compatibility with other DB's. Postgres was
> > > > "the" pioneer in this area, but similar functionality is now available in
>other DB's.
> > >
> > > Could you
On Wed, Nov 15, 2000 at 02:42:24PM +0100, Zeugswetter Andreas SB wrote:
>
> > > We need the 7.0 style for compatibility with other DB's. Postgres was
> > > "the" pioneer in this area, but similar functionality is now available in other
>DB's.
> >
> > Could you explain? PostgreSQL cant be comp
> > We need the 7.0 style for compatibility with other DB's. Postgres was
> > "the" pioneer in this area, but similar functionality is now available in other
>DB's.
>
> Could you explain? PostgreSQL cant be compatible in C level, why
> the SQL compatibility? (I mean the LANGUAGE 'C' specific
On Mon, Nov 13, 2000 at 09:58:30AM +0100, Zeugswetter Andreas SB wrote:
>
> > > because as said, it can be any other language besides C and also
> > > the 'AS file' is weird.
> >
> > This is interesting. It allows us to control the default behavour of
> > "C". I would vote to default to 7.0-sty
> > because as said, it can be any other language besides C and also
> > the 'AS file' is weird.
>
> This is interesting. It allows us to control the default behavour of
> "C". I would vote to default to 7.0-style when no version is used for
> 7.1, then default to 7.1 style in 7.2 and later. W
At 20:30 11/11/00 -0500, Tom Lane wrote:
>
>The current fmgr implementation requires PL handlers to be newC or
>newInternal. That could be relaxed, but I don't see any reason to do
>so, since an old-style handler would be incapable of handling null
>arguments/results or supporting triggers.
OK,
At 21:15 11/11/00 -0500, Bruce Momjian wrote:
>
>This is interesting. It allows us to control the default behavour of
>"C". I would vote to default to 7.0-style when no version is used for
>7.1, then default to 7.1 style in 7.2 and later. We don't need
>backward C function compatibility for more
> > No. 'C' is really a misnomer, since it does NOT imply anything about
> > whether the code is in C or not --- in theory you could use any language
> > that's link-compatible with C. What LANGUAGE 'C' really implies is
> > "dynamically linked, compiled function following fmgr interface
> > con
On Sat, Nov 11, 2000 at 08:30:48PM -0500, Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
...
> > It does avoid "language 'evenNewerC'" in the furture.
>
> How so? It appears to me it would just move the 'evenNewerFoo'
> dirtiness to a different keyword, which would still be essent
Philip Warner <[EMAIL PROTECTED]> writes:
> Is it the PL manager stuff that requires the new interface for all
> languages, or is it up to the PL implementor to choose the language for
> their handler?
The current fmgr implementation requires PL handlers to be newC or
newInternal. That could be
At 10:55 11/11/00 -0500, Tom Lane wrote:
>
>Just outputting a warning is possible, but it still leaves you with a
>broken database after you reload your 7.0 dump file :-(. (And there
>isn't any supported way to fix it, short of reloading all your function
>definitions...) I thought about the fix
Philip Warner <[EMAIL PROTECTED]> writes:
> At 12:07 10/11/00 -0500, Tom Lane wrote:
>> Something's got to be done about this --- not being able to load
>> 7.0 dump files will not do.
> I assume modifying pg_dump for 7.0.x is not an option,
Not really ...
> would
> there be any value in modifyi
At 12:07 10/11/00 -0500, Tom Lane wrote:
>
>Something's got to be done about this --- not being able to load
>7.0 dump files will not do.
>
I assume modifying pg_dump for 7.0.x is not an option, since we really need
to support loading databases from historical dump files. If so, then would
there
So new-style C functions are language "newC"?
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I don't really have a better idea, but consider if you installed 7.1 into
> > /opt/postgres71: then this dump will load the old version of plpgsql.sl.
>
> True, but absolute paths in a dump file
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I don't really have a better idea, but consider if you installed 7.1 into
> /opt/postgres71: then this dump will load the old version of plpgsql.sl.
True, but absolute paths in a dump file are a different (and
long-standing) issue.
> Assuming tha
Tom Lane writes:
> Philip pointed out awhile back that it does not work to load a 7.0.*
> dump into current sources if the dumped database contains any
> procedural language definitions. The dumped handler-function
> definitions will look like
>
> CREATE FUNCTION "plpgsql_call_handler" ( ) RETU
Philip pointed out awhile back that it does not work to load a 7.0.*
dump into current sources if the dumped database contains any
procedural language definitions. The dumped handler-function
definitions will look like
CREATE FUNCTION "plpgsql_call_handler" ( ) RETURNS opaque AS
'/opt/postgres/l
30 matches
Mail list logo
