Philip Warner <[EMAIL PROTECTED]> writes:
> ISTM that this problem comes about because we allow an external function to
> be defined incorrectly (ie. the db says it returns type A, the function
> really returns type B) - and we should be addressing that problem.
Well, yeah. 7.3 is trying to ti
Philip Warner <[EMAIL PROTECTED]> writes:
> At 11:27 PM 12/09/2002 -0400, Tom Lane wrote:
>> You mean hardwire the names "plpgsql_language_handler", etc, as being
>> ones that should return such-and-such instead of OPAQUE?
> No; I actually mean modifying the function definition macros
> (PG_FUNC
At 01:42 PM 13/09/2002 +1000, Philip Warner wrote:
>Not all functions would need to use these, but when a user defines a
>function they could be checked. And in the case of the plpgsql handlers,
>they would of course be defined.
ISTM that this problem comes about because we allow an external f
At 11:27 PM 12/09/2002 -0400, Tom Lane wrote:
>You mean hardwire the names "plpgsql_language_handler", etc, as being
>ones that should return such-and-such instead of OPAQUE?
No; I actually mean modifying the function definition macros
(PG_FUNCTION_INFO etc) to allow function definitions to (opt
Philip Warner <[EMAIL PROTECTED]> writes:
> At 01:37 PM 12/09/2002 -0400, Tom Lane wrote:
>> Er ... what has that got to do with this?
> When a user issues a 'CREATE FUNCTION' call, the fmgr can check the return
> type, and create it with the correct return type (with warning). We just
> need t
At 01:37 PM 12/09/2002 -0400, Tom Lane wrote:
> > What about extending the function manager macros to know about return
> types
> > (at least for builtin types)?
>
>Er ... what has that got to do with this?
When a user issues a 'CREATE FUNCTION' call, the fmgr can check the return
type, and cre
Oliver Elphick <[EMAIL PROTECTED]> writes:
> On Thu, 2002-09-12 at 15:54, Tom Lane wrote:
>> Only if people dump their old databases with 7.3 pg_dump; which is an
>> assumption I'd rather not make if we can avoid it.
> I don't understand.
> The only pg_dump we can fix is 7.3.
Certainly. But if
Philip Warner <[EMAIL PROTECTED]> writes:
> At 10:31 AM 12/09/2002 -0400, Tom Lane wrote:
>> Does anyone see a cleaner answer than re-allowing OPAQUE for PL
>> handlers?
> What about extending the function manager macros to know about return types
> (at least for builtin types)?
Er ... what has
Oliver Elphick wrote:
On Thu, 2002-09-12 at 15:54, Tom Lane wrote:
Oliver Elphick <[EMAIL PROTECTED]> writes:
On Thu, 2002-09-12 at 15:31, Tom Lane wrote:
Does anyone see a cleaner answer than re-allowing OPAQUE for PL
handlers?
On Thu, 2002-09-12 at 15:54, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > On Thu, 2002-09-12 at 15:31, Tom Lane wrote:
> >> Does anyone see a cleaner answer than re-allowing OPAQUE for PL
> >> handlers?
>
> > Can't you just special case the language handlers when dumping <7.3
At 10:31 AM 12/09/2002 -0400, Tom Lane wrote:
>Does anyone see a cleaner answer than re-allowing OPAQUE for PL
>handlers?
What about extending the function manager macros to know about return types
(at least for builtin types)?
P
Oliver Elphick <[EMAIL PROTECTED]> writes:
> On Thu, 2002-09-12 at 15:31, Tom Lane wrote:
>> Does anyone see a cleaner answer than re-allowing OPAQUE for PL
>> handlers?
> Can't you just special case the language handlers when dumping <7.3 and
> change 'RETURNS opaque' to 'RETURNS language_handle
On Thu, 2002-09-12 at 15:31, Tom Lane wrote:
> Does anyone see a cleaner answer than re-allowing OPAQUE for PL
> handlers?
Can't you just special case the language handlers when dumping <7.3 and
change 'RETURNS opaque' to 'RETURNS language_handler'? That's all that
is needed to let them be resto
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Well, our whole goal was to get rid of the opaque thing entirely so I am
> not sure if we want to keep that going. In fact, I am not sure it is
> even possible to remap opaque because it now is represented by so many
> other values.
We do still allow O
14 matches
Mail list logo
