Re: Extensions vs PGXS' MODULE_PATHNAME handling

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 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?

I share your view on the directory and module_pathname, but though that
maybe encoding could be the source of subtle errors and that users would
be happy to know what PostgreSQL is using. But well, that's not holding
enough water now that I think some more about it.

> 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?

I'm not set one way or the other and won't share another opinion on
that :)

> 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.

Ok.

> 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.

I would expect the author to check with something like

WHERE installed = '1.0' and available = '1.2'

But again, the preference here is about either "cluttering" the default
output more than necessary or having to type a WHERE clause to double
check your setup. No strong opinion here, just a preference…

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support