As discussed in this thread, we could wrap the parsing with a try/catch to avoid stopping the execution unexpectedly.

I don't mind doing this change, but I need to understand if:

• A - we should catch the error and return the default value as a string;
• B - write code to start parsing array's as default values;

Heya! Me again 👋🏻

What is the "raw" javascript representation of a default value as returned by pg in this case? Is it a buffer, or a string representation?

Hey there,

So, their documentation is a bit incomplete:
    https://node-postgres.com/api/types

But their code shows that the text value of json[]/jsonb[] (postgres representation) is parsed into an array of json's (javascript representation).

    https://github.com/brianc/node-pg-types/blob/8594bc6befca3523e265022f303f1376f679b5dc/lib/textParsers.js#L179-L180

Hmm odd, that makes me wonder why the parse default value step fails then. Technically speaking, passing an array of JS objects to JSON.parse() shouldn't crash like that 🤔

But in this case, the default value that we are trying to parse is ARRAY[]. JSON.parse is allergic to anything that doesn't start with a {

@ntma Oh I see, when you mentioned:

But their code shows that the text value of json[]/jsonb[] (postgres representation) is parsed into an array of json's (javascript representation).

I thought you meant that it would be returned as actual valid JSON (as ARRAY[] isn't actually JSON ofc)

I am sorry for the confusion @rijkvanzanten .

TLDR we have in one side the parsing that the pg module does to retrieve values from the database, which I believe is not related to this issue.

On the other side we have the parsing that knex-schema-inspector does to extract information from schema definitions. And if I am not wrong, currently this parsing does not support the PostgreSQL syntax for array's as default values (since there is no direct mapping to JavaScript for Array[]).

@rijkvanzanten Isn't this (kinda) fixed with #117 since we now return unparsed JSON strings?

Yes!