Hi 2016-03-03 0:27 GMT+01:00 Jim Nasby <jim.na...@bluetreble.com>:
> On 3/2/16 3:52 PM, Pavel Stehule wrote: > >> Right, and it's arguably dubious that that doesn't already work. >> Unfortunately, these % things are just random plpgsql parser hacks, >> not >> real types. Maybe this should be done in the main PostgreSQL parser >> with parameter hooks, if we wanted this feature to be available >> outside >> plpgsql as well. >> >> >> I am not fan to propagate this feature outside PLpgSQL - it is possible >> new dependency between database object, and the cost is higher than >> benefits. >> > > I fail to see how it'd be a dependency. I'd expect it to look up the type > when you run the command, just like plpgsql does. I think it'd be useful to > have. > if we publish this feature to SQL, then somebody can use it in table definition CREATE TABLE a(a int); CREATE TABLE b(a a.a%TYPE) And the people expecting the living relation between table a and table b. So when I do ALTER a.a, then b.a should be changed. What if I drop a.a or drop a? So this is reason, why I don't would this feature in SQL side. Regards Pavel > > That said, I think that should be a completely separate patch and > discussion. Lets at least get it into plpgsql first. > > As for the array of element/element of array feature; I agree it would be > nice, but we're pretty late in the game for that, and I don't see why that > couldn't be added later. > > -- > Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX > Experts in Analytics, Data Architecture and PostgreSQL > Data in Trouble? Get it in Treble! http://BlueTreble.com >
