| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: type info refactoring |
| Date: | 2010-10-31 17:01:55 |
| Message-ID: | 23667.1288544515@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> ... I assumed that TypeInfo would be
> embedded in other structs directly, rather than a pointer and palloc.
Yeah, that would avoid the extra-pallocs complaint, although it might be
notationally a bit of a PITA in places like equalfuncs.c. I think that
would end up needing a separate COMPARE_TYPEINFO_FIELD macro instead of
being able to treat it like a Node* field.
But I'm still wondering whether it's smart to try to promote all of this
fundamentally-auxiliary information to first-class status. It's really
unclear to me that that will end up being a net win either conceptually
or notationally.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri Fontaine | 2010-10-31 17:16:36 | Re: ALTER OBJECT any_name SET SCHEMA name |
| Previous Message | Heikki Linnakangas | 2010-10-31 16:59:45 | Re: ALTER OBJECT any_name SET SCHEMA name |