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
13 matches
Mail list logo
