Folks,

I'd like to take the TODO item that reads, "Add support for arrays of
complex types," but before I start patching, I'd like to see whether
what I'm about to do makes any sense:

1. In src/backend/commands/tablecmds.c, change DefineRelation as
follows:

* After the first call to heap_create_with_catalog, construct and
do another call to for the array type.

* Add an appropriate pg_depend entry.

2. Change RemoveRelation to reflect the above.

3. Change TypeRename appropriately, whatever that turns out to be.

Does the above make sense? Have I missed anything critical?

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

David Fetter <david@fetter.org> writes:
> 1. In src/backend/commands/tablecmds.c, change DefineRelation as
> follows:
> * After the first call to heap_create_with_catalog, construct and
> do another call to for the array type.

I'm still not happy about the idea of doing this for every relation
(and doing it for sequences and indexes would be the height of
wastefulness). How about we only do it for composite types?

> * Add an appropriate pg_depend entry.
> 2. Change RemoveRelation to reflect the above.

You only need one of those two: either you drop by hand or you let the
dependency machinery deal with it. Not both.

> Does the above make sense? Have I missed anything critical?

Ummm ... making it actually work? Possibly that just falls out, but I'm
not sure.

If it turns out that it does Just Work, you might take a stab at arrays
of domains too.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Tom Lane wrote:
> David Fetter <david@fetter.org> writes:
>> 1. In src/backend/commands/tablecmds.c, change DefineRelation as
>> follows:
>> * After the first call to heap_create_with_catalog, construct and
>> do another call to for the array type.
>
> I'm still not happy about the idea of doing this for every relation
> (and doing it for sequences and indexes would be the height of
> wastefulness). How about we only do it for composite types?
>


I'm not happy about that. I agree that indexes and sequences should not be
done, but can we please do plain table types? I would be OK if we skipped
catalog tables, if that would make you happier.

cheers

andrew




---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Fri, Mar 02, 2007 at 06:42:14PM -0600, Andrew Dunstan wrote:
> > I'm still not happy about the idea of doing this for every relation
> > (and doing it for sequences and indexes would be the height of
> > wastefulness). How about we only do it for composite types?
>
> I'm not happy about that. I agree that indexes and sequences should not be
> done, but can we please do plain table types? I would be OK if we skipped
> catalog tables, if that would make you happier.

Two thoughts:

1. Make the array types only when someone actually uses them (create a
table with it or something).

2. Make a command: CREATE TYPE ARRAY OF "foo";

The latter has the benefit of not restricting it to an arbitrary choice
of types, you could accept both domains and composite types here. I
don't think it's unreasonable to require people to predeclare their
usage of array-of-compostite-type.

Perhaps change the word "CREATE" to "DECLARE". I'm thinking of the
explicit declaration of shell types as precedent here.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFF6XTRIB7bNG8LQkwRApfrAJ9p84Q6Eol5Hc6oU9GY1z jpINwBJgCeJOmp
Ynyoa4Ya673gyPIFbA4ezUU=
=iBUN
-----END PGP SIGNATURE-----

Martijn van Oosterhout wrote:
> On Fri, Mar 02, 2007 at 06:42:14PM -0600, Andrew Dunstan wrote:
>
>>> I'm still not happy about the idea of doing this for every relation
>>> (and doing it for sequences and indexes would be the height of
>>> wastefulness). How about we only do it for composite types?
>>>
>> I'm not happy about that. I agree that indexes and sequences should not be
>> done, but can we please do plain table types? I would be OK if we skipped
>> catalog tables, if that would make you happier.
>>
>
> Two thoughts:
>
> 1. Make the array types only when someone actually uses them (create a
> table with it or something).
>
> 2. Make a command: CREATE TYPE ARRAY OF "foo";
>
> The latter has the benefit of not restricting it to an arbitrary choice
> of types, you could accept both domains and composite types here. I
> don't think it's unreasonable to require people to predeclare their
> usage of array-of-compostite-type.
>
> Perhaps change the word "CREATE" to "DECLARE". I'm thinking of the
> explicit declaration of shell types as precedent here.
>
>
>
#2 would be fine with me - not keen on #1.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Sat, Mar 03, 2007 at 09:06:11AM -0500, Andrew Dunstan wrote:
>
>
> Martijn van Oosterhout wrote:
> >On Fri, Mar 02, 2007 at 06:42:14PM -0600, Andrew Dunstan wrote:
> >
> >>>I'm still not happy about the idea of doing this for every relation
> >>>(and doing it for sequences and indexes would be the height of
> >>>wastefulness). How about we only do it for composite types?
> >>>
> >>I'm not happy about that. I agree that indexes and sequences should not be
> >>done, but can we please do plain table types? I would be OK if we skipped
> >>catalog tables, if that would make you happier.
> >>
> >
> >Two thoughts:
> >
> >1. Make the array types only when someone actually uses them (create a
> >table with it or something).

This doesn't sound so great.

> >2. Make a command: CREATE TYPE ARRAY OF "foo";
> >
> >The latter has the benefit of not restricting it to an arbitrary choice
> >of types, you could accept both domains and composite types here.

I'm thinking that DOMAINs over simple types should just automatically
get corresponding array types. We don't yet support DOMAINs over
complex types, but when we do, whatever we do with arrays of regular
complex types should apply the same way.

> >I don't think it's unreasonable to require people to predeclare
> >their usage of array-of-compostite-type.
> >
> >Perhaps change the word "CREATE" to "DECLARE". I'm thinking of the
> >explicit declaration of shell types as precedent here.
> >
> #2 would be fine with me - not keen on #1.

Per your earlier suggestion in IRC, I'm picturing a polymorphic
function like

pg_catalog.array_for(typepoid OID)
pg_catalog.array_for(typename NAME)
pg_catalog.array_for(typenamespace NAME, typename NAME)

I don't see a good reason to allow putting array types in a different
schema from their base types.

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

"David Fetter" <david@fetter.org> writes:

>> >2. Make a command: CREATE TYPE ARRAY OF "foo";
>> >
>> >The latter has the benefit of not restricting it to an arbitrary choice
>> >of types, you could accept both domains and composite types here.
>
> I'm thinking that DOMAINs over simple types should just automatically
> get corresponding array types. We don't yet support DOMAINs over
> complex types, but when we do, whatever we do with arrays of regular
> complex types should apply the same way.

Just a thought, but if we supported domains over complex types we could kill
two birds with one stone and say when you create a domain the array type is
created and that's how you have to refer to arrays over complex types.
Probably doesn't make anything easier though. Just a thought.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

David Fetter wrote:
> Per your earlier suggestion in IRC, I'm picturing a polymorphic
> function like
>
> pg_catalog.array_for(typepoid OID)
> pg_catalog.array_for(typename NAME)
> pg_catalog.array_for(typenamespace NAME, typename NAME)
>
> I don't see a good reason to allow putting array types in a different
> schema from their base types.
>
>

Actually, I think I prefer Martijns simple SQL extension suggestion better.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

On Fri, Mar 02, 2007 at 06:59:50PM -0500, Tom Lane wrote:
> David Fetter <david@fetter.org> writes:
> > 1. In src/backend/commands/tablecmds.c, change DefineRelation as
> > follows:
> > * After the first call to heap_create_with_catalog, construct and
> > do another call to for the array type.
>
> I'm still not happy about the idea of doing this for every relation
> (and doing it for sequences and indexes would be the height of
> wastefulness). How about we only do it for composite types?

How about doing it for user-defined tables, views and composite types,
and skipping ?

> > * Add an appropriate pg_depend entry.
> > 2. Change RemoveRelation to reflect the above.
>
> You only need one of those two: either you drop by hand or you let the
> dependency machinery deal with it. Not both.

pg_depend it is, then

> > Does the above make sense? Have I missed anything critical?
>
> Ummm ... making it actually work? Possibly that just falls out, but
> I'm not sure.
>
> If it turns out that it does Just Work, you might take a stab at
> arrays of domains too.

OK.

I noticed something in src/backend/commands/tablecmds.c which worries
me, namely that it ignores functions and views. It should at least be
checking that the typeoid isn't in pg_proc.prorettype or
pg_proc.proargtypes, and if possible, the DECLARE section of pl/pgsql
functions.

Is there a way to do SQL at that place in the back-end, or is there
some different kind of Magick(TM) needed to access these kinds of
things at that level?

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

David Fetter <david@fetter.org> writes:
> I noticed something in src/backend/commands/tablecmds.c which worries
> me, namely that it ignores functions and views.

What?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq