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
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
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)
"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
"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
"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
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
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
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
