Re: Protocol V3 questions (StartupMessage and ParameterStatus)

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(at)xythos(dot)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 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. 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(at)xythos(dot)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