Thread: Output filter for psql
I have mentioned this as a side issue in another thread. I thought that it would be useful to start a separate thread for this. Perhaps this won't be so difficult to code and we can forget all about the ReST discussion. So, I guess psql should pass XML to the user's filter and simply dump its output to the screen. Is XML the best format? It would allow us to pass meta information. For example, we could pass the border setting so that the filter could change its output based on it. As for syntax, I'm not sure how difficult it would be to code but I was thinking something like this: \filter <format> <path> This would create a new format that can be set with pset. For example: \filter rest ~/my_filter ... \pset format rest I would imagine that the filter command would normally go into ~/.psqlrc since it would only be activated by the pset call. -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
On Thu, 8 Jan 2009 17:22:04 -0500 "D'Arcy J.M. Cain" <darcy@druid.net> wrote: > So, I guess psql should pass XML to the user's filter and simply dump > its output to the screen. Is XML the best format? It would allow us > to pass meta information. For example, we could pass the border > setting so that the filter could change its output based on it. Pardon me while I argue with myself. :-) I wonder if XML isn't overkill for this. I think that we only need three pieces of information:- The column headings- The column types (in case the user wants it)- The data XML would be difficult from both the server as well as the user. Perhaps the simplest thing for both sides is simply CSV with an extra row for type. For example: person_id,person_name,person_email int,text,text 1,"darcy","D'Arcy Cain" 2,"tom","Tom Lane" 3,"bruce","Bruce Momjian" ...etc. The user could choose to ignore the second line if he doesn't need it. I suppose we could define another line with options that we could define for meta information such as the border setting and the table name and whatever we define later. E.g: "table:person","border:3","funky:option with \":\"" -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
D'Arcy J.M. Cain wrote: > On Thu, 8 Jan 2009 17:22:04 -0500 > "D'Arcy J.M. Cain" <darcy@druid.net> wrote: > >> So, I guess psql should pass XML to the user's filter and simply dump >> its output to the screen. Is XML the best format? It would allow us >> to pass meta information. For example, we could pass the border >> setting so that the filter could change its output based on it. >> > > Pardon me while I argue with myself. :-) > > I wonder if XML isn't overkill for this. I think that we only need > three pieces of information: > - The column headings > - The column types (in case the user wants it) > - The data > > XML would be difficult from both the server as well as the user. > Perhaps the simplest thing for both sides is simply CSV with an extra > row for type. For example: > > person_id,person_name,person_email > int,text,text > 1,"darcy","D'Arcy Cain" > 2,"tom","Tom Lane" > 3,"bruce","Bruce Momjian" > ...etc. > > The user could choose to ignore the second line if he doesn't need it. > I suppose we could define another line with options that we could > define for meta information such as the border setting and the table > name and whatever we define later. E.g: > > "table:person","border:3","funky:option with \":\"" > Why do you want to add this extra information? psql doesn't output it now, and IIRC your original proposal didn't do it either. cheers andrew
On Wed, 28 Jan 2009 14:08:54 -0500 Andrew Dunstan <andrew@dunslane.net> wrote: > D'Arcy J.M. Cain wrote: > > I suppose we could define another line with options that we could > > define for meta information such as the border setting and the table > > name and whatever we define later. E.g: > > > > "table:person","border:3","funky:option with \":\"" > > Why do you want to add this extra information? psql doesn't output it > now, and IIRC your original proposal didn't do it either. It mentioned including meta information. I'm not sure that I really care if I get it but we may want it in general, if not now then later, and it would be something that would be extremely hard to retrofit. If we start out with just the table and perhaps the border setting we can always add more later if we find we need it. If we don't start with something then adding an extra line later will cause all sorts of heartache. -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
D'Arcy J.M. Cain wrote: > On Wed, 28 Jan 2009 14:08:54 -0500 > Andrew Dunstan <andrew@dunslane.net> wrote: > >> D'Arcy J.M. Cain wrote: >> >>> I suppose we could define another line with options that we could >>> define for meta information such as the border setting and the table >>> name and whatever we define later. E.g: >>> >>> "table:person","border:3","funky:option with \":\"" >>> >> Why do you want to add this extra information? psql doesn't output it >> now, and IIRC your original proposal didn't do it either. >> > > It mentioned including meta information. I'm not sure that I really > care if I get it but we may want it in general, if not now then later, > and it would be something that would be extremely hard to retrofit. If > we start out with just the table and perhaps the border setting we can > always add more later if we find we need it. If we don't start with > something then adding an extra line later will cause all sorts of > heartache. > > For CSV it's likely to cause a headache right at the start. CSV with a single header line is a well known and mostly understood format. I don't know of any CSV processor (including ours) that handles more than one header line. This is actually an example of why XML is not such a bad choice. It is rich enough that a processor is unlikely to be confused by metadata, and capable of being turned into almost any other format you might want with little difficulty. cheers andrew