Barry Lind <blind@xythos.com> writes:
> I have started working on the new protocol and have a question. Since
> the startup packet now lets you set GUC parameters, what happens if you
> send an invalid GUC parameter?
The same thing that happens if you send it via PGOPTIONS: the server
errors out. Any error at that point is considered FATAL, so the
connection drops:
$ PGOPTIONS="--nonesuch=1" psql
psql: FATAL: 'nonesuch' is not a valid option name
$
> At the time the startup packet is issued I don't yet know
> what version of the server I am talking to, so I don't know what
> parameter names to use. Therefore I think the result of passing a
> unknown parameter name should not be fatal.
Hm. I think this could be argued either way, but I'm willing to listen.
Anyone else have an opinion?
Seems like you would also have the problem that some values of some
parameters might be legal for some server versions and not others.
Wouldn't you also want a bogus value for a known parameter to not be
a fatal error? I am not certain how far we can promise that that would
work.
> Also it might be useful to know what parameters got set and which did
> not (although once one knows the server version, this probably can be
> infered from the server version).
Rejecting a parameter would still be a WARNING, at least, and also
there's the ParameterStatus reports (for the parameters that reporting
applies to).
regards, tom lane