Thread: Protocol V3 question
Tom, 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? (I don't have anything working yet so I can't test this for myself). The reason I am asking is that the names of GUC parameters can change between releases of the server. So in 7.5 the 'datestyle' parameter might be renamed to 'dateformat' (unlikely but possible). 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. 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). It would probably be worth a note or two in the protocol docs explaining how this will work across server releases so that all client implementors are aware of this issue. thanks, --Barry
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
Tom, While implementing the V3 protocol I have come across the following questions: 1) Why does the StartupMessage not follow the documentation. It appears that an extra undocumented \0 is necessary after the parameter name/value pairs. Or at least that is what I needed to get a successful connection. So when I tried to send: "user\0test\0database\0test\0" with a message length of 32 (4+4+24) I got the error "invalid startup packet layout: expected terminator as last byte", however if I send "user\0test\0database\0test\0\0" with a message length of 33, then it works. Is this a doc bug, or a code problem? 2) In looking at the ParameterStatus messages that I am getting back from the server, I have a question about the value being returned for datestyle. Since I am in the process of converting to the new protocol, I am still sending a query that issues a "set datestyle to 'ISO'". The ParameterStatus response I get from this query is: "DateStyle\0ISO with US (NonEuropean) conventions". I would have expected "DateStyle\0ISO". It appears that the value reported by ParameterStatusisn't actually a valid value, since if you try to issue a set datestyle to 'ISO with US (NonEuropean) conventions' you get an error message. So my question is how does one parse the value of the datestyle parameter? It appears (although I haven't verified) that the value will change depending on language since I am assuming the words 'with' and 'conventions' will be translated. I would have expected that set and show would use the same set of possible values. thanks, --Barry PS. Tom, since your spam filter blocks my email, I can't send directly to you, thus I need to CC the hackers list. Can you whitelist me? Or is it OK to continue sending these questions to the hackers list?
Barry Lind <blind@xythos.com> writes: > Why does the StartupMessage not follow the documentation. It appears > that an extra undocumented \0 is necessary after the parameter > name/value pairs. This is a doc bug; the terminator is supposed to be there. Thanks for catching it. > In looking at the ParameterStatus messages that I am getting back from > the server, I have a question about the value being returned for > datestyle. Since I am in the process of converting to the new protocol, > I am still sending a query that issues a "set datestyle to 'ISO'". The > ParameterStatus response I get from this query is: "DateStyle\0ISO with > US (NonEuropean) conventions". I would have expected "DateStyle\0ISO". Why? If you do "SHOW datestyle" you will get the full thing. > It appears that the value reported by ParameterStatus isn't > actually a valid value, since if you try to issue a set datestyle to > 'ISO with US (NonEuropean) conventions' you get an error message. Hmm. This is not ParameterStatus' fault per se: the SHOW routine for DateStyle is producing a string that the SET routine for it won't take. We could either alter the SHOW routine to produce "ISO, US" or alter the SET routine to take the more verbose string. Or decree that it's not a problem. Any opinions out there? > It appears (although I haven't verified) that the value will change > depending on language since I am assuming the words 'with' and > 'conventions' will be translated. I'm not sure about that. If so, it's definitely a problem, but I dunno whether that string gets localized. > PS. Tom, since your spam filter blocks my email, I can't send directly > to you, thus I need to CC the hackers list. Can you whitelist me? Done. Sorry, didn't realize there was a problem. But it's probably good to get this stuff onto the list, as well. BTW, the protocol doc changes that I committed yesterday evening are not yet reflected in CVS tip, but I hope to commit fixes today that bring the code back in sync with the docs. regards, tom lane