aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/execGrouping.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2011-05-22 15:13:35 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2011-05-22 15:15:07 -0400
commit219dfae4e1b0ca7cbc0b2f0f7740e01657964c07 (patch)
tree495c0a3798f64146a00e9d926060c15b6da51b9a /src/backend/executor/execGrouping.c
parentfae625e7b9824ec64f770904108089ff4fbcf093 (diff)
downloadpostgresql-219dfae4e1b0ca7cbc0b2f0f7740e01657964c07.tar.gz
postgresql-219dfae4e1b0ca7cbc0b2f0f7740e01657964c07.zip
Make plpgsql provide the typmods for its variables to the main parser.
Historically we didn't do this, even though we had the information, because plpgsql passed its Params via SPI APIs that only include type OIDs not typmods. Now that plpgsql uses parser callbacks to create Params, it's easy to insert the right typmod. This should generally result in lower surprise factors, because a plpgsql variable that is declared with a typmod will now work more like a table column with the same typmod. In particular it's the "right" way to fix bug #6020, in which plpgsql's attempt to return an anonymous record type is defeated by stricter record-type matching checks that were added in 9.0. However, it's not impossible that this could result in subtle behavioral changes that could break somebody's existing plpgsql code, so I'm afraid to back-patch this change into released branches. In those branches we'll have to lobotomize the record-type checks instead.
Diffstat (limited to 'src/backend/executor/execGrouping.c')
0 files changed, 0 insertions, 0 deletions