Re: Show type in psql SELECT

David,

* David Fetter (david(at)fetter(dot)org) wrote:
> Not everyone uses libpq, so my argument for making it available at the
> SQL level stands.

Ok, if they're not using libpq then presumably they're using some
custom-written app which speaks the PostgreSQL protocol- and guess what,
this information is there too.

> That may have been so in 2001, but even then we were getting our rear
> ends handed to us by an outfit that, despite its massive technical
> inferiority, took end-user usability very carefully into account.

If you'd like to propose something concrete around this, please do so.
Thus far, it looks like pure hand-waving to me.

> The way I look at it, easy things should be easy, and this is an easy
> thing.

Then please make a specific proposal. What would this "SET" option do?
How would an application make use of it? Certainly, psql would have no
need of it to do exactly what's proposed here.

> I don't know how you got the idea that the server should decide this
> from what I wrote.

Because you suggested a server-side SET parameter? What else would one
presume from what you've written?

> What I suggested was that we make this
> available--not mandatory or auto-detected--via the SQL API, namely
> with a SET command.

It's available through the PG frontend/backend protocol and available
through libpq. In fact, you can't turn off getting the information. If
you're curious about the data types of a table but don't want to
actually query the table, you can query it through information_schema
and/or pg_catalog.

A specific proposal around what is missing would be much more useful to
this discussion than complaining about people trying to make sense of
hand waving.

Thanks,

Stephen