| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com> |
| Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Using Expanded Objects other than Arrays from plpgsql |
| Date: | 2024-10-20 19:19:00 |
| Message-ID: | 1357717.1729451940@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com> writes:
> On Sun, Oct 20, 2024 at 10:13 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The other problem is that plpgsql only knows how to do such expansion
>> for arrays, and it's not obvious how to extend that part.
> Perhaps a third member function for ExpandedObjectMethods that formalizes
> the expansion interface like found in DatumGetExpandedArray? I closely
> follow that same pattern in my code.
The trouble is we don't have an expanded object to consult at this
point --- only a flat Datum. plpgsql has hard-wired knowledge that
it's okay to apply expand_array if the datatype passes the typisarray
tests, but I'm pretty unclear on how to provide similar knowledge for
extension datatypes.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-10-20 19:32:32 | Re: Help Resolving Compiler Errors With enable-dtrace Flag |
| Previous Message | Barry Walker | 2024-10-20 19:02:06 | Re: Help Resolving Compiler Errors With enable-dtrace Flag |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joel Jacobson | 2024-10-20 21:03:42 | Re: Add pg_ownerships and pg_privileges system views |
| Previous Message | Michel Pelletier | 2024-10-20 18:25:30 | Re: Using Expanded Objects other than Arrays from plpgsql |