On Wed, Feb 3, 2021, at 21:41, Joel Jacobson wrote:
>Otherwise I think it would be more natural to change both is_array and is_opt
>to boolean[] with the same cardinality as fkcols and pkcols,
>to allow unnest()ing of them as well.
Another option would perhaps be to add a new
system view in src/ba
On Mon, Feb 1, 2021, at 21:03, Tom Lane wrote:
>"Joel Jacobson" writes:
>> The is_array OUT parameter doesn't say which of the possibly many fkcols
>> that is the array column.
>
>Yeah, I didn't write the sgml docs yet, but the comments explain that
>the array is always the last fkcol. Maybe som
I wrote:
> * It would now be possible to remove the PGNSP and PGUID kluges
> entirely in favor of plain BKI_LOOKUP references to pg_namespace
> and pg_authid. The catalog header usage would get a little
> more verbose: BKI_DEFAULT(PGNSP) becomes BKI_DEFAULT(pg_catalog)
> and BKI_DEFAULT(PGUID) bec
"Joel Jacobson" writes:
> On Tue, Feb 2, 2021, at 17:00, Tom Lane wrote:
>> Appreciate the review! Please confirm if you agree with above
>> analysis.
> Yes, I agree with the analysis.
Cool, thanks. I've pushed it now.
regards, tom lane
On Tue, Feb 2, 2021, at 17:00, Tom Lane wrote:
>No, I think it's correct as-is (and this is one reason that I chose to
>have two separate FK entries for cases like this). confrelid can be
>zero in rows that are not FK constraints. However, such a row must
>also have empty confkey. The above entr
"Joel Jacobson" writes:
> I could only find one minor error,
> found by running the regression-tests,
> and then using the query below to compare "is_opt"
> with my own "zero_values" in my tool
> that derives its value from pg_catalog content.
> ...
> I therefore think is_opt should be changed to
On Tue, Feb 2, 2021, at 04:27, Tom Lane wrote:
>Attachments:
>add-catalog-foreign-key-info-2.patch
Very nice.
I could only find one minor error,
found by running the regression-tests,
and then using the query below to compare "is_opt"
with my own "zero_values" in my tool
that derives its value fr
"Joel Jacobson" writes:
> The is_array OUT parameter doesn't say which of the possibly many fkcols that
> is the array column.
Yeah, I didn't write the sgml docs yet, but the comments explain that
the array is always the last fkcol. Maybe someday that won't be
general enough, but we can cross t
On Mon, Feb 1, 2021, at 20:33, Joel Jacobson wrote:
>Suggestions on how to fix:
>
>* Make is_array an boolean[], and let each element represent the is_array
>value for each fkcols element.
>
>* Change interface to be more like information_schema, and add a
>"ordinal_position" column, and return e
Hi again,
After trying to use pg_get_catalog_foreign_keys() to replace what I had before,
I notice one ambiguity which I think is a serious problem in the
machine-readable context.
The is_array OUT parameter doesn't say which of the possibly many fkcols that
is the array column.
One example:
Could it be an idea to also add
OUT can_be_zero boolean
to pg_get_catalog_foreign_keys()'s out parameters?
This information is useful to know if one should be doing an INNER JOIN or a
LEFT JOIN on the foreign keys.
The information is mostly available in the documentation already,
but not qu
Very nice. Thanks to this patch, I can get rid of my own parse-catalogs.pl hack
and use pg_get_catalog_foreign_keys() instead.
+1
I can with high confidence assert the correctness of
pg_get_catalog_foreign_keys()'s output,
as it matches the lookup tables for the tool I'm hacking on precisely:
12 matches
Mail list logo
