Re: Identifying no-op length coercions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Identifying no-op length coercions
Date: 2011-05-23 19:01:40
Message-ID: 18282.1306177300@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Noah Misch <noah(at)leadboat(dot)com> writes:
> Good deal. Given that conclusion, the other policy decision I anticipate
> affecting this particular patch is the choice of syntax. Presumably, it will be
> a new common_func_opt_item. When I last looked at the keywords list and tried
> to come up with something, these were the best I could do:

> CREATE FUNCTION ... PARSER MAPPING helperfunc(args)
> CREATE FUNCTION ... PLANS CONVERSION helperfunc(args)

We could go with your previous idea of not bothering to expose this in
the SQL syntax. Given that the helper function is going to have a
signature along the lines of "(internal, internal) -> internal", it's
going to be difficult for anyone to use it for non-builtin functions
anyhow.

But if you really don't like that, what about

TRANSFORM helperfunctionname

Although TRANSFORM isn't currently a keyword for us, it is a
non-reserved keyword in SQL:2008, and it seems possible that we might
someday think about implementing the associated features.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-05-23 19:08:35 Re: 9.1 support for hashing arrays
Previous Message Bruce Momjian 2011-05-23 18:57:27 Re: [BUGS] BUG #6034: pg_upgrade fails when it should not.