Re: Extensions vs PGXS' MODULE_PATHNAME handling

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> and pg_available_extension_versions that produces a row per install
>> script, with columns
>>
>> name
>> version ((name, version) is primary key)
>> comment
>> requires
>> relocatable
>> schema
>>
>> where the last four columns can vary across versions due to secondary
>> control files.

> I like this primary key because that's also the one for debian stable
> distributions:) Joking apart, aren't we missing the encoding somewhere?

I intentionally left out columns that seem like extension implementation
details rather than things users of the extension need to know. Hence,
no directory, encoding, or module_pathname. There's no fundamental
reason not to include these, I guess, although maybe there could be some
security objection to showing directory. But do we need 'em?

>> The output might look like this:
>>
>> 1.0 1.1 1.0--1.1
>> 1.1 1.2 1.1--1.2
>> unpackaged 1.0 unpackaged--1.0
>> 1.0 1.2 1.0--1.1--1.2
>> 1.0 unpackaged
>> 1.1 1.0
>> 1.1 unpackaged
>> 1.2 1.1
>> 1.2 1.0
>> 1.2 unpackaged
>> unpackaged 1.1 unpackaged--1.0--1.1
>> unpackaged 1.2 unpackaged--1.0--1.1--1.2

> What about having this chain column be an array of version strings? If
> you want to see it this way, use array_to_string(path, '--')

I was thinking the other way --- you can split it with
regexp_split_to_array (or regexp_split_to_table) if you want to, but
having a compact human-readable form is probably the most important
case. It's not a big deal either way though. Anyone else want to
vote?

>> where the first three rows correspond to available update scripts and
>> the rest are synthesized.

> The ordering is not clearly apparent, but I don't think it matters.

Sorry, I only meant that in this example I put the rows coming from
single scripts first. I didn't mean to suggest that the function would
guarantee any particular output ordering.

>> (Looking at this, it looks like it could get pretty bulky pretty
>> quickly. Maybe we should eliminate all rows in which the path would be
>> NULL? Or just eliminate rows in which the target doesn't have an
>> install script, which would remove the three rows with target =
>> unpackaged in the above example?)

> Removing NULL path rows seems the best option to me.

Yeah, possibly. I'm a bit concerned about cases where the author meant
to provide an update path and forgot: it would be fairly obvious in this
representation but maybe you could keep making the same oversight if the
row's not there at all. Also, it's easy enough to write "where path is
not null" if you want to filter the rows that way.

regards, tom lane