Re: Processing data from table using awk.

On Tue, Oct 6, 2015 at 10:04 AM, John McKown <john(dot)archie(dot)mckown(at)gmail(dot)com>
wrote:

> I'm wanting to do some reporting on data which I have an a PostgreSQL
> table. For lack of anything better, I've decided to see if I can do it in
> GNU awk. OK, using Perl with DBI might be a better idea, I'll grant you
> that. Or maybe Python or Ruby (which I don't know). But out of shear
> cussedness, I'm going to see what I can do in gawk. What I don't see is a
> way to get the data out of PostgreSQL and into my awk program. Does anybody
> know of a way to do this, short of "cheating" by using psql? Yes, I know
> that I could do something like (BASH on Linux/Fedora 22 x86_64):
>
> awk -f some-program.awk <(echo 'SELECT a, b, c, d FROM schema.table ORDER
> BY a' | psql dbname)
>

​While not an expert on awk I believe this ^ is how the program is designed
to function​.

> What I was hoping for was a "Dynamic Extension" (dll) which would allow
> "native" use of PostgreSQL, or may ODBC. But I haven't found any. Have I
> missed anything? If I were to create such a beastie, would it be of any use
> to others? I guess, in this, I'm wondering what "report writer" most are
> using when psql just doesn't have sufficient capability.
>
>
​
Birt, Jasper Reports, or Crystal Reports to name a few well-known ones.
​

> Yeah, sometimes I'm just plain stupid & pig headed. But then it will be a
> "leaning experience" (with associated scars, I'm sure).
>

​If you don't understand the nature of awk or *NIX in general (dll is a
Window's thing) you are likely going to end up with much worse than scars.
Amputation is likely to be required.

​
To a large degree one is expected to use BASH (or another shell scripting
language) if they want to compose programs from *NIX commands. To choose
to use awk but then discard psql makes little sense. If you need something
more holistic and/or capable you should just upgrade to a general-purpose
language (e.g., Perl) or a custom-built solution (e.g. Birt).

David J.