On Mon, Jan 21, 2019 at 9:46 PM Tom Lane wrote:
> Perhaps this also gives some impetus to the lets-use-identifiers-
> not-numbers approach that Andrew was pushing. I didn't care for
> that too much so far as an extension's own internal references
> are concerned, but for cross-extension
I wrote:
> [ discussion about ways to let extension C code find out object OIDs ]
I wanted to close out this thread, for the time being, by saying that
I'm not expecting to get anything done about it for v12. It seems
pretty late in the dev cycle to be proposing any major new user-visible
Hi,
On 2019-01-21 19:41:26 -0500, Tom Lane wrote:
> Andres Freund writes:
> > It'd be more
> > realistic to create a new zone at UINT32_MAX - something, but that'd
> > likely still conflict in plenty installations (thanks to toast and WITH
> > OIDS tables). I'm curious as to how to solve that,
> "Tom" == Tom Lane writes:
>> 1. easier to read and maintain
Tom> The SQL-level API that I'm imagining would look roughly like
Tom> a command like this at the end of an extension's script:
Tom> ALTER EXTENSION extname SET MAP
Tom> OBJECT 1 IS FUNCTION foo(int, int),
Tom> OBJECT
>
>
> Thoughts?
I have a feeling this is over-engineering in slightly different direction,
solving the way for hack to work instead of original problem.
What's currently happening in PostGIS is that there are functions that need
to perform index-based lookups.
Postgres is unable to plan this
On 01/21/19 21:45, Tom Lane wrote:
> are concerned, but for cross-extension references it seems a
> lot better to be looking for "postgis / function_foo_int_int"
> than for "postgis / 3".
I wonder if postgis might offer a .h file with FUNCTION_POSTGIS_FOO_INT_INT
defined as 3, which extensions
Chapman Flack writes:
> On 01/21/19 18:52, Tom Lane wrote:
>> I'm probably going to push forward with the OID mapping idea instead.
> As it happens, I'd been recently thinking[1] about a way that certain
> SQL/XML functionality could be provided by a pluggable selection of
> different
On 01/21/19 18:52, Tom Lane wrote:
> I'm probably going to push forward with the OID mapping idea instead.
As it happens, I'd been recently thinking[1] about a way that certain
SQL/XML functionality could be provided by a pluggable selection of
different extensions.
And I think a use case like
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> I thought about extending the extension infrastructure to provide
> Tom> some way of retrieving relevant OIDs. We could imagine, for
> Tom> instance, that an extension script has a way to say "this function
> Tom> is object number
> "Tom" == Tom Lane writes:
Tom> I thought about extending the extension infrastructure to provide
Tom> some way of retrieving relevant OIDs. We could imagine, for
Tom> instance, that an extension script has a way to say "this function
Tom> is object number three within this extension",
Andres Freund writes:
> On 2019-01-21 18:52:05 -0500, Tom Lane wrote:
>> Yes, I said in so many words that I was proposing increasing
>> FirstNormalObjectId. I do not think the issues with pg_upgrade itself
>> are insoluble --- it would need some historical knowledge about what
>>
Hi,
On 2019-01-21 18:52:05 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-01-20 18:50:33 -0500, Tom Lane wrote:
> >> In [1] I propose that we should allow extensions to get their hands
> >> on the ability to transform function calls as per "protransform" and
> >> to generate lossy
Andres Freund writes:
> On 2019-01-20 18:50:33 -0500, Tom Lane wrote:
>> In [1] I propose that we should allow extensions to get their hands
>> on the ability to transform function calls as per "protransform" and
>> to generate lossy index quals based on items in WHERE clauses. The
>> APIs to
Hi,
On 2019-01-20 18:50:33 -0500, Tom Lane wrote:
> In [1] I propose that we should allow extensions to get their hands
> on the ability to transform function calls as per "protransform" and
> to generate lossy index quals based on items in WHERE clauses. The
> APIs to give an extension control
On Sun, Jan 20, 2019 at 06:50:33PM -0500, Tom Lane wrote:
> A larger issue is whether "hand out some OIDs on-demand" is a
> sustainable strategy. I think that it is, if we encourage extensions
> to assign fixed OIDs only to objects they really need to. In thirty-ish
> years of core PG
On Mon, Jan 21, 2019 at 12:25:16AM +, Andrew Gierth wrote:
> > "Tom" == Tom Lane writes:
>
> Tom> A larger issue is whether "hand out some OIDs on-demand" is a
> Tom> sustainable strategy.
>
> No.
>
> Not for any concerns over availability of oids, but simply from the fact
> that we
Chapman Flack writes:
> On 01/20/19 19:43, Tom Lane wrote:
>>> If the extension script could somehow be informed at CREATE EXTENSION time
>>> of what its OID is, that would clear the way for ALTER EXTENSION RENAME, no?
>> And it remembers that where?
> Top level answer: up to the extension
Andrew Gierth writes:
> In fact I suggest that "there shall be no registries of third parties"
> be made a formal project policy.
You're a decade or two too late for that; see pg_statistic.h.
In any case, it's not like this issue applies to every extension anybody
might want to make. Only
On 01/20/19 19:43, Tom Lane wrote:
>> If the extension script could somehow be informed at CREATE EXTENSION time
>> of what its OID is, that would clear the way for ALTER EXTENSION RENAME, no?
>
> And it remembers that where?
Top level answer: up to the extension author.
Next level answer:
> "Tom" == Tom Lane writes:
Tom> I'm not exactly following this concern. I wasn't imagining that
Tom> we'd assign each individual OID ourselves, but rather give out
Tom> blocks of OIDs. Admittedly, the blocks can't be huge, but it
Tom> doesn't seem to me that this'd create an impossible
Chapman Flack writes:
> On 01/20/19 18:50, Tom Lane wrote:
>> we make a catalog entry showing that object number three has OID
>> thus-and-so, and then that catalog entry can be consulted to get
>> the right OID (by C code that has hard-wired knowledge that object
>> number three is the function
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> A larger issue is whether "hand out some OIDs on-demand" is a
> Tom> sustainable strategy.
> No.
> Not for any concerns over availability of oids, but simply from the fact
> that we have no business whatsoever inserting ourselves into
On 01/20/19 18:50, Tom Lane wrote:
> we make a catalog entry showing that object number three has OID
> thus-and-so, and then that catalog entry can be consulted to get
> the right OID (by C code that has hard-wired knowledge that object
> number three is the function it cares about). This is
> "Tom" == Tom Lane writes:
Tom> A larger issue is whether "hand out some OIDs on-demand" is a
Tom> sustainable strategy.
No.
Not for any concerns over availability of oids, but simply from the fact
that we have no business whatsoever inserting ourselves into the
extension development
In [1] I propose that we should allow extensions to get their hands
on the ability to transform function calls as per "protransform" and
to generate lossy index quals based on items in WHERE clauses. The
APIs to give an extension control at the right points seem pretty
straightforward, but
25 matches
Mail list logo
