David, * David Fetter (da...@fetter.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
signature.asc
Description: Digital signature
