-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
> NOTICE: identifier
> "this_is_a_really_long_identifier_for_a_prepared_statement_name_ok"
> will be truncated to
> "this_is_a_really_long_identifier_for_a_prepared_statement_name_"
> PREPARE
...
> The ORM could use a shorter identifier, but it supports multiple backends
> and this is probably not something in their test suite. In addition it
> actually works!
For now. If it really works, then by definition it does not /need/ to
be that long, as the truncated version is not blowing things up.
> So I am sharing this with the list to see what people think. Is this a
> configuration bug? An ORM bug? A postgres bug? An unfortunate
> interaction?
Part ORM fault, part Postgres. We really should be throwing something
stronger than a NOTICE on such a radical change to what the user
asked for. I'd lobby for WARNING instead of ERROR, but either way, one
could argue that applications would be more likely to notice and
fix themselves if it was stronger than a NOTICE.
> If it's a postgres bug, what is the fix? Make the identifier max size
> longer?
I'd also be in favor of this, in addition to upgrading from a NOTICE. We
no longer have any technical reason to keep it NAMEDATALEN, with
the listen/notify rewrite, correct? If so, I'd like to see the max bumped
to at least 128 to match the default SQL spec length for similar items.
> Set a hard limit and ERROR instead of truncating and NOTICE?
> Both? Neither because that would break backward compatibility?
My vote is WARNING and bump limit to 128 in 9.3. That's the combo most
likely to make dumb applications work better while not breaking
existing smart ones.
- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201211172246
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAlCoWpYACgkQvJuQZxSWSsi4NwCfQfq7NEQ3xiLpPZLsu0I9iGT4
pOAAmgPEsm2iYCPiVfzMEM2EX2nihQE9
=wLpM
-----END PGP SIGNATURE-----
