Dimitri Fontaine <dimi...@2ndquadrant.fr> writes: > Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers