get JOIN table as array of results with PostgreSQL/NodeJS

This is easy to do with pg-promise:

function buildTree(t) {    const v = q => t.any('SELECT id, value FROM votes WHERE question_id = $1', q.id)        .then(votes => {            q.votes = votes;            return q;        });    return t.map('SELECT * FROM questions', undefined, v).then(a => t.batch(a));}db.task(buildTree)    .then(data => {        console.log(data); // your data tree    })    .catch(error => {        console.log(error);    });

The same as above, but using ES7 async/await syntax:

await db.task(async t => {    const questions = await t.any('SELECT * FROM questions');    for(const q of questions) {        q.votes = await t.any('SELECT id, value FROM votes WHERE question_id = $1', [q.id]);    }    return questions;});// method "task" resolves with the correct data tree

API: map, any, task, batch

Related questions:

• Get a parents + children tree with pg-promise
• Conditional task with pg-promise

And if you want to use just a single query, then using PostgreSQL 9.4 and later syntax you can do the following:

SELECT json_build_object('id', q.id, 'content', q.content, 'votes',    (SELECT json_agg(json_build_object('id', v.id, 'value', v.value))     FROM votes v WHERE q.id = v.question_id))FROM questions q

And then your pg-promise example would be:

const query =    `SELECT json_build_object('id', q.id, 'content', q.content, 'votes',        (SELECT json_agg(json_build_object('id', v.id, 'value', v.value))         FROM votes v WHERE q.id = v.question_id)) json    FROM questions q`;    const data = await db.map(query, [], a => a.json);

And you definitely will want to keep such complex queries in external SQL files. See Query Files.

Conclusion

The choice between the two approaches presented above should be based on the performance requirements of your application:

• The single-query approach is faster, but is somewhat difficult to read or extend, being fairly verbose
• The multi-query approach is easier to understand and to extend, but it is not great for performance, due to dynamic number of queries executed.

UPDATE-1

The following related answer offers more options, by concatenating child queries, which will give a much improved performance: Combine nested loop queries to parent result pg-promise.

UPDATE-2

Another example added, using ES7 async/await approach.

Please think simple way, May be I am right, I use knex js

 let allpost = knex        .select([            'questions.id',            'question.content',            knex.raw('json_agg(v.*) as votes')        ])        .from('questions')        .leftJoin('votes as v', 'questions.id', 'v.question_id')        .groupBy('questions.id');

sql-toolkit does exactly this. It's a node library built for pg-promise which allows you to write regular native SQL and receive back properly structured (nested) pure business objects, without either having to split up the query or rewrite it with json_build_object.

For example:

class Article extends BaseDAO {  getBySlug(slug) {    const query = `      SELECT        ${Article.getSQLSelectClause()},        ${Person.getSQLSelectClause()},        ${ArticleTag.getSQLSelectClause()},        ${Tag.getSQLSelectClause()}      FROM article      JOIN person        ON article.author_id = person.id      LEFT JOIN article_tags        ON article.id = article_tags.article_id      LEFT JOIN tag        ON article_tags.tag_id = tag.id      WHERE article.slug = $(slug);  `;  return this.one(query, { slug });  // OUTPUT: Article {person: Person, tags: Tags[Tag, Tag, Tag]}}

The select clause uses the business object "getSQLSelectClause" methods to save tedium in typing the columns, as well as ensure no collisions of names (nothing magical going on, and could just be written out instead).

The this.one is a call into sql-toolkits base DAO class. It is responsible for structuring the flat result records into a nice nested structure.

(Also notice that it is "one" which matches our mental model for the SQL. The DAO methods for one, oneOrNone, many, and any ensure their count against the number of generated top level business objects - not the number of rows the sql expression returns!)

Check out the repository for details on how to set it up on top of pg-promise. It's strictly an enhancement, and does not seek to abstract out pg-promise (you still set up pg-promise and can use it directly). (Disclamer, I am the author of sql-toolkit.)