Обсуждение: 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