Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
In the short run it might be best to do it in scan.l after all.

I have not come up with a way of doing that and handling the bytea case.

AFAICS we have no realistic choice other than to reject \0 in SQL
literals; to do otherwise requires API changes throughout that stack of
modules.  And once you admit \0 is no good, it's not clear that
\somethingelse is any better for bytea-using clients.  Moreover, given
that we are moving away from backslash escapes as fast as we can sanely
travel, expending large amounts of energy to make them work better
doesn't seem like a good use of development manpower.

Perhaps we're talking at cross purposes.

The problem with doing encoding validation in scan.l is that it lacks context. Null bytes are only the tip of the bytea iceberg, since any arbitrary sequence of bytes can be valid for a bytea. So we can only do validation of encoding on a literal when we know it isn't destined for a bytea. That's what I haven't come up with a way of doing in the scanner (and as you noted upthread it's getting pretty darn late in the cycle for us to be looking for ways to do things).

I still don't see why it's OK for us to do validation from the foo_recv functions but not the corresponding foo_in functions. At least in the short term that would provide us with fairly complete protection against accepting invalidly encoded data into the database, once we fix up chr(), without having to mess with the scanner, parser, COPY code etc. We could still get corruption from UDFs and UDTs - it's hard to see how we can avoid that danger. Yes, we would need to make sure that any additions to the type system acted properly, and yes we should fix up any validation inefficiencies (like possibly inlining calls in the UTF8 validation code). Personally, I don't see those as killer objections.



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not

Reply via email to