PostgreSQL supports Composite Types which are just like a basic type, but are defined by a table or view. You can then have a column in a table or view that is a Composite Type of another table or view.
https://www.postgresql.org/docs/current/static/rowtypes.html
When using Composite Types in my schema, I get the following error starting PostGraphQL:
Error: Schema must contain unique named types but contains multiple types named "PostInspiration".
at invariant (/usr/lib/node_modules/postgraphql/node_modules/graphql/jsutils/invariant.js:19:11)
at typeMapReducer (/usr/lib/node_modules/postgraphql/node_modules/graphql/type/schema.js:192:29)
at /usr/lib/node_modules/postgraphql/node_modules/graphql/type/schema.js:219:22
at Array.forEach (native)
at /usr/lib/node_modules/postgraphql/node_modules/graphql/type/schema.js:210:29
at typeMapReducer (/usr/lib/node_modules/postgraphql/node_modules/graphql/type/schema.js:221:7)
at typeMapReducer (/usr/lib/node_modules/postgraphql/node_modules/graphql/type/schema.js:187:12)
at /usr/lib/node_modules/postgraphql/node_modules/graphql/type/schema.js:219:22
at Array.forEach (native)
at /usr/lib/node_modules/postgraphql/node_modules/graphql/type/schema.js:210:29
This is a bit of a contrived example, but it recreates the issue:
forum_example schema for v2.0.forum_example.post_inspiration view:``` sql
CREATE OR REPLACE VIEW forum_example.post_inspiration AS
SELECT t1.id,
t1.headline,
t1.topic,
t1.body
FROM forum_example.post t1
WHERE t1.topic = 'inspiration';
COMMENT ON VIEW forum_example.post_inspiration
IS 'inspiration posts';
```
forum_example.posts view that uses the forum_example.post_inspiration view as a Composite Type for two columns:``` sql
CREATE OR REPLACE VIEW forum_example.posts AS
SELECT t1.id,
t1.headline,
t1.topic,
t1.body,
-- ARRAY Composite Type of the forum_example.post_inspiration view.
ARRAY( SELECT post_inspiration.::forum_example.post_inspiration AS post_inspiration
FROM forum_example.post_inspiration
WHERE post_inspiration.topic = t1.topic
ORDER BY post_inspiration.id) AS inspirations,
-- Composite Type of the forum_example.post_inspiration view.
( SELECT post_inspiration.::forum_example.post_inspiration AS post_inspiration
FROM forum_example.post_inspiration
WHERE post_inspiration.id = t1.id
) AS inspiration
FROM forum_example.post t1;
COMMENT ON VIEW forum_example.posts
IS 'posts';
```
I believe this error is happening because you introspect the forum_example.post_inspiration type from the view by that name and then introspect the forum_example.post_inspiration type again from the columns with that type on the forum_example.posts view. If you DROP the forum_example.posts view, there is no error.
So PostGraphQL does support composite types, this problem is a bit different though. We treat the composite types for views/tables differently then for normal composite types as views/tables will have extra fields like those for relations. In this case the logic is conflicting. I鈥檒l work on a fix :+1:
Hello @calebmer, any news on this?
I just started postgraphql on a database, had the first issue on Naming conflict when building object. Cannot have two definitions for property 'stForce2d'. then forced the schema to something else than public and had the Schema must contain unique named types but contains multiple types named... error.
Hi, @FGRibreau
This is a different issue, it looks like you have PostGIS installed in your public schema. Currently the way PostGIS names some of its functions (such as stForce2d) and dumps them in the public schema leads to naming conflicts. Try starting PostGraphQL with another schema like: postgraphql --schema forum_example 馃憤
@calebmer That was my immediate thought, but @FGRibreau has already accounted for the steps in #260 and now has a type conflict - I believe it's on-topic.
Very old issue. Close @benjie ?
I don鈥檛 think v4 has this issue because it generates the types in a different way.
Most helpful comment
So PostGraphQL does support composite types, this problem is a bit different though. We treat the composite types for views/tables differently then for normal composite types as views/tables will have extra fields like those for relations. In this case the logic is conflicting. I鈥檒l work on a fix :+1: