si...@2ndquadrant.com (Simon Riggs) writes:
> Just for the record, I've never ever met anyone that said "Oh, this
> \d syntax makes so much sense. I'm a real convert to Postgres now
> you've shown me this". The reaction is always the opposite one;
> always negative. Which detracts from our efforts elsewhere.

If we're opening up the code to change this, it makes a lot of sense
to try to Do It Really Right so that we're not going over this again
and again.

I think we're seeing several things that suck, and I'm quite sure I
have not yet heard an answer that resolves it all.  Things that have
become clear:

 1.  \d isn't exactly the most intuitive thing ever

     And it's pretty clear that we have been heading into some
     increasingly cryptic bits of fruit salad of
     \dfzb+-meta-bucky-alt-foo

     Having SHOW THIS and SHOW THAT which are a bit more readily
     guessed would be somewhat nice.

 2.  information_schema doesn't have some useful things that we'd like
     it to have

     Listing databases would be nice.  Unfortunately, "ANSI didn't
     define a way to do that, so we can't add it."

     Alas, I don't see a good way to improve on this :-(

 3.  The \? commands are *solely* for psql, and it would be nice to
     have the Improvement work on server side so it's not only usable
     with the one client.

 4.  It would be Mighty Useful for whatever extensions get defined
     server-side to also be "relational" so that they can be usefully
     scripted in ways NOT vulnerable to screen size, output hackery,
     and such.

     - I've seen too many QA scripts that do awk parsing of output of
       psql "\d" commands that are vulnerable to all kinds of awfulness.
       Add an "updated-on" column to the output, and suddenly everything
       breaks.

     - I'd sure like to be able to write queries that *don't* involve
       array smashing or using "grep" on \z output to analyze object
       permissions.

     - \? output is often *not* amenable to this, as it sometimes has
       extra bits of data hierarchy in it.  And "array aggregation."

There's a certain risk of things being overspecified such that there's
*no* solution, but I don't think that forcibly *has* to happen.

But the answers I'm seeing thus far run slipshod across too many of
these things, so I don't see that we have arrived at actual solutions
yet.
-- 
let name="cbbrowne" and tld="gmail.com" in String.concat "@" [name;tld];;
http://linuxfinances.info/info/linuxdistributions.html
Rules of the Evil Overlord #77. "If I have a fit of temporary insanity
and decide to give  the hero the chance to reject a  job as my trusted
lieutentant,  I will  retain enough  sanity to  wait until  my current
trusted  lieutenant  is  out  of  earshot before  making  the  offer."
<http://www.eviloverlord.com/>

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to