On Tue, Jun 12, 2018 at 8:41 AM, Andrew Dunstan
wrote:
> UNBOUNDED would be terrible. It does not mean the same thing as UNBOUND.
>
> Perhaps something like NO CHECK would meet the case, i.e. we're not checking
> the link at function creation time.
>
> I haven't thought through the other implicati
On 2018-06-12 15:05:16 +0100, Andrew Gierth wrote:
> > "Tom" == Tom Lane writes:
>
> > Andrew Gierth writes:
> >> The real question is why check_function_bodies doesn't cover this;
> >> there's a comment in fmgr_c_validator that this is deliberate, but it's
> >> rather unclear what the a
On 06/12/2018 11:09 AM, Geoff Winkless wrote:
On Tue, 12 Jun 2018 at 15:44, Christian Ullrich wrote:
I did wonder about "NO CHECK" but wasn't sure if having two words
would make the parser change more complex.
DEFERRED?
That's a good shout. I wouldn't mind either of those choices.
So can
On Tue, 12 Jun 2018 at 15:44, Christian Ullrich wrote:
> > I did wonder about "NO CHECK" but wasn't sure if having two words
> > would make the parser change more complex.
>
> DEFERRED?
That's a good shout. I wouldn't mind either of those choices.
So can I assume at least that no-one has an obje
* On 2018-06-12 16:35, Geoff Winkless wrote:
On Tue, 12 Jun 2018 at 13:41, Andrew Dunstan wrote:
UNBOUNDED would be terrible. It does not mean the same thing as UNBOUND.
Indeed. I agree.
Perhaps something like NO CHECK would meet the case, i.e. we're not
checking the link at function crea
On Tue, 12 Jun 2018 at 13:41, Andrew Dunstan
wrote:
> On 06/12/2018 06:48 AM, Geoff Winkless wrote:
> > +| AS 'obj_file', 'link_symbol' [UNBOUNDED]
> > (I know UNBOUNDED isn't quite the word - BINDLATE would be better -
> > but I figured I should try to use an existing reserved keyword...)
>
>
>
> >> The real question is why check_function_bodies doesn't cover this;
> >> there's a comment in fmgr_c_validator that this is deliberate, but it's
> >> rather unclear what the advantage is supposed to be:
>
> Tom> Error detection, ie did you spell the C symbol name correctly.
>
> Right, but
> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> The real question is why check_function_bodies doesn't cover this;
>> there's a comment in fmgr_c_validator that this is deliberate, but it's
>> rather unclear what the advantage is supposed to be:
Tom> Error detection, ie did you
Andrew Gierth writes:
> The real question is why check_function_bodies doesn't cover this;
> there's a comment in fmgr_c_validator that this is deliberate, but it's
> rather unclear what the advantage is supposed to be:
Error detection, ie did you spell the C symbol name correctly.
On 06/12/2018 08:46 AM, Andrew Gierth wrote:
"Andrew" == Andrew Dunstan writes:
Andrew> Perhaps something like NO CHECK would meet the case, i.e. we're
Andrew> not checking the link at function creation time.
The real question is why check_function_bodies doesn't cover this;
there's a c
> "Andrew" == Andrew Dunstan writes:
Andrew> Perhaps something like NO CHECK would meet the case, i.e. we're
Andrew> not checking the link at function creation time.
The real question is why check_function_bodies doesn't cover this;
there's a comment in fmgr_c_validator that this is delibe
On 06/12/2018 06:48 AM, Geoff Winkless wrote:
Hi All
Is it possible to use CREATE FUNCTION to link a shared library that
doesn't yet exist? I don't think it is, but I might be missing
something.
If not, would it be something that people would be open to a patch
for? I'm thinking of e.g.
CRE
This thing also bites PostGIS upgrades.
When distro's packaging system decides to upgrade PostGIS, or both
Postgres/PostGIS at the same time, you may often get to a situation when
you only have one version of PostGIS .so installed, and it's not the one
referenced in catalog. There are workarounds
Hi All
Is it possible to use CREATE FUNCTION to link a shared library that
doesn't yet exist? I don't think it is, but I might be missing
something.
If not, would it be something that people would be open to a patch
for? I'm thinking of e.g.
CREATE [ OR REPLACE ] FUNCTION
name ( [ [ argmode
14 matches
Mail list logo
