On Fri, Jan 29, 2010 at 2:08 AM, Pavel Stehule wrote:
>>
>> First, you can't just remove support for the escape syntax from \d
>> commands without some discussion of whether or not that's the right
>> thing to do, and I don't think it is. The cases where this will
>> potentially cause a problem a
>
> First, you can't just remove support for the escape syntax from \d
> commands without some discussion of whether or not that's the right
> thing to do, and I don't think it is. The cases where this will
> potentially cause a problem are limited to those where the input is
> invalidly encoded,
On Thu, Jan 28, 2010 at 11:59 AM, Pavel Stehule wrote:
> 2010/1/28 Robert Haas :
>> On Thu, Jan 28, 2010 at 4:53 AM, Pavel Stehule
>> wrote:
>>> 2010/1/27 Robert Haas :
On Mon, Jan 25, 2010 at 7:36 AM, Pavel Stehule
wrote:
> I hope, so this version is more readable and more clean
2010/1/28 Robert Haas :
> On Thu, Jan 28, 2010 at 4:53 AM, Pavel Stehule
> wrote:
>> 2010/1/27 Robert Haas :
>>> On Mon, Jan 25, 2010 at 7:36 AM, Pavel Stehule
>>> wrote:
I hope, so this version is more readable and more clean. I removed
some not necessary checks.
>>>
>>> This still s
On Thu, Jan 28, 2010 at 4:53 AM, Pavel Stehule wrote:
> 2010/1/27 Robert Haas :
>> On Mon, Jan 25, 2010 at 7:36 AM, Pavel Stehule
>> wrote:
>>> I hope, so this version is more readable and more clean. I removed
>>> some not necessary checks.
>>
>> This still seems overly complicated to me. I sp
2010/1/27 Robert Haas :
> On Mon, Jan 25, 2010 at 7:36 AM, Pavel Stehule
> wrote:
>> I hope, so this version is more readable and more clean. I removed
>> some not necessary checks.
>
> This still seems overly complicated to me. I spent a few hours today
> working up the attached patch. Let me
On Mon, Jan 25, 2010 at 7:36 AM, Pavel Stehule wrote:
> I hope, so this version is more readable and more clean. I removed
> some not necessary checks.
This still seems overly complicated to me. I spent a few hours today
working up the attached patch. Let me know your thoughts.
...Robert
*** a
Hello
I hope, so this version is more readable and more clean. I removed
some not necessary checks.
regards
Pavel
2010/1/22 Robert Haas :
> On Fri, Jan 22, 2010 at 7:19 AM, Pavel Stehule
> wrote:
>> here is new variant. Add scan_state flag "valid" and enhance
>> protection against execution b
2010/1/22 Robert Haas :
> On Fri, Jan 22, 2010 at 7:19 AM, Pavel Stehule
> wrote:
>> here is new variant. Add scan_state flag "valid" and enhance
>> protection against execution broken statement.
>
> This doesn't make sense to me. You've changed the way \set is handled
> - in a way that doesn't
On Fri, Jan 22, 2010 at 7:19 AM, Pavel Stehule wrote:
> here is new variant. Add scan_state flag "valid" and enhance
> protection against execution broken statement.
This doesn't make sense to me. You've changed the way \set is handled
- in a way that doesn't seem particularly appropriate to me
Hello
here is new variant. Add scan_state flag "valid" and enhance
protection against execution broken statement.
Regards
Pavel Stehule
2010/1/22 Pavel Stehule :
> 2010/1/22 Robert Haas :
>> On Thu, Jan 21, 2010 at 2:25 PM, Pavel Stehule
>> wrote:
>>> 2010/1/21 Robert Haas :
On Thu, Jan 2
2010/1/22 Robert Haas :
> On Thu, Jan 21, 2010 at 2:25 PM, Pavel Stehule
> wrote:
>> 2010/1/21 Robert Haas :
>>> On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule
>>> wrote:
add to state structure field like lexer_error. This field will be
checked before execution
it could be ugly
On Thu, Jan 21, 2010 at 2:25 PM, Pavel Stehule wrote:
> 2010/1/21 Robert Haas :
>> On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule
>> wrote:
>>> add to state structure field like lexer_error. This field will be
>>> checked before execution
>>> it could be ugly for metacommands, there will be lot
2010/1/21 Robert Haas :
> On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule
> wrote:
>> add to state structure field like lexer_error. This field will be
>> checked before execution
>> it could be ugly for metacommands, there will be lot of new checks :(
>
> Eh? The only places where we should nee
On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule wrote:
> add to state structure field like lexer_error. This field will be
> checked before execution
> it could be ugly for metacommands, there will be lot of new checks :(
Eh? The only places where we should need new tests are the places
that che
2010/1/21 Robert Haas :
> On Thu, Jan 21, 2010 at 11:57 AM, Pavel Stehule
> wrote:
>> 2010/1/21 Robert Haas :
>>> On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas wrote:
On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'd like to proceed by committing an ini
On Thu, Jan 21, 2010 at 11:57 AM, Pavel Stehule wrote:
> 2010/1/21 Robert Haas :
>> On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas wrote:
>>> On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
Robert Haas writes:
> I'd like to proceed by committing an initial patch which changes the
>
2010/1/21 Robert Haas :
> On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas wrote:
>> On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
>>> Robert Haas writes:
I'd like to proceed by committing an initial patch which changes the
"Escaping Strings for Inclusion in SQL Commands" to use a
On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas wrote:
> On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> I'd like to proceed by committing an initial patch which changes the
>>> "Escaping Strings for Inclusion in SQL Commands" to use a
>>> with one per function (as we
On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'd like to proceed by committing an initial patch which changes the
>> "Escaping Strings for Inclusion in SQL Commands" to use a
>> with one per function (as we do in
>> surrounding functions) and consolidates it with th
Robert Haas writes:
> I'd like to proceed by committing an initial patch which changes the
> "Escaping Strings for Inclusion in SQL Commands" to use a
> with one per function (as we do in
> surrounding functions) and consolidates it with the following section,
> "Escaping Binary Strings for Inc
On Tue, Jan 19, 2010 at 3:13 PM, Tom Lane wrote:
>> It seems to me that it might be
>> sensible to do it this way:
>
>> 1. Do a locale-aware scan of the input string and count the number of
>> characters we need to escape (num_to_escape).
>> 2. If num_to_escape is 0, fast path: allocate len+3 byte
Robert Haas writes:
> Do you think we should malloc 2n+X bytes all the time, or do you want
> to scan the string once to determine how much space is needed and then
> allocate exactly that much space?
I'd vote for two scans, as I think we'll soon decide 2n doesn't cut it
anyway. One of the issue
On Tue, Jan 19, 2010 at 2:38 PM, Tom Lane wrote:
> As long as it's documented it's okay ... probably ... note that
> conditionally inserting E would get us right back to the place where
> an unsafe usage might appear to work fine in light testing. Maybe
> prepend a space only if prepending E?
Th
Robert Haas writes:
> On Tue, Jan 19, 2010 at 2:01 PM, Tom Lane wrote:
>> * include boundary quotes (and E too in the literal case). This would
>> imply telling people they should leave whitespace around the value in
>> the constructed query ... or should we insert leading/trailing spaces
>> to
On Tue, Jan 19, 2010 at 2:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... I think as
>> long as we're adding a new function, we should make it behave sanely.
>> We could even take the opportunity to go back and add a saner version
>> of PQescapeStringConn.
>
> Well, it's a bit late in the dev
2010/1/19 Robert Haas :
> On Tue, Jan 19, 2010 at 1:43 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Updated patch attached. I still think this is a bizarre API.
>>
>> Well, if we had it to do over I'm sure we'd have done it differently,
>> but the functions are there now and we aren't going to
Robert Haas writes:
> ... I think as
> long as we're adding a new function, we should make it behave sanely.
> We could even take the opportunity to go back and add a saner version
> of PQescapeStringConn.
Well, it's a bit late in the devel cycle to be inventing from scratch,
but if we did want t
On Tue, Jan 19, 2010 at 1:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> Updated patch attached. I still think this is a bizarre API.
>
> Well, if we had it to do over I'm sure we'd have done it differently,
> but the functions are there now and we aren't going to change them ...
I agree, but
Robert Haas writes:
> Updated patch attached. I still think this is a bizarre API.
Well, if we had it to do over I'm sure we'd have done it differently,
but the functions are there now and we aren't going to change them ...
regards, tom lane
--
Sent via pgsql-hackers m
On Tue, Jan 19, 2010 at 12:54 PM, Pavel Stehule wrote:
>> I think what you're saying is that you agree with Tom's position that
>> the new escaping function should not add the necessary surrounding
>> quotes, instead leaving that to the user. Is that correct?
>
> yes
Updated patch attached. I s
2010/1/19 Robert Haas :
> On Tue, Jan 19, 2010 at 4:13 AM, Pavel Stehule
> wrote:
>> 2010/1/18 Robert Haas :
>>> On Mon, Jan 18, 2010 at 3:26 PM, Tom Lane wrote:
Robert Haas writes:
> ... Also, I prefer an
> API where the escaping function does include the quotes, so I've done
>>>
On Tue, Jan 19, 2010 at 4:13 AM, Pavel Stehule wrote:
> 2010/1/18 Robert Haas :
>> On Mon, Jan 18, 2010 at 3:26 PM, Tom Lane wrote:
>>> Robert Haas writes:
... Also, I prefer an
API where the escaping function does include the quotes, so I've done
it that way in the attached patc
2010/1/18 Robert Haas :
> On Mon, Jan 18, 2010 at 3:26 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> ... Also, I prefer an
>>> API where the escaping function does include the quotes, so I've done
>>> it that way in the attached patch.
>>
>> IMO this function should act as much like PQescapeStr
On Mon, Jan 18, 2010 at 3:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... Also, I prefer an
>> API where the escaping function does include the quotes, so I've done
>> it that way in the attached patch.
>
> IMO this function should act as much like PQescapeStringConn as possible.
Generally
Robert Haas writes:
> ... Also, I prefer an
> API where the escaping function does include the quotes, so I've done
> it that way in the attached patch.
IMO this function should act as much like PQescapeStringConn as possible.
Random differences like including or not including outer quotes don't
On Mon, Jan 18, 2010 at 2:20 PM, Pavel Stehule wrote:
> 2010/1/18 Robert Haas :
>> On Mon, Jan 18, 2010 at 1:52 PM, Pavel Stehule
>> wrote:
>>> 2010/1/18 Robert Haas :
On Sun, Jan 17, 2010 at 2:04 PM, Pavel Stehule
wrote:
> I rewrote patch so now interface for PQescapeIdentConn i
2010/1/18 Robert Haas :
> On Mon, Jan 18, 2010 at 1:52 PM, Pavel Stehule
> wrote:
>> 2010/1/18 Robert Haas :
>>> On Sun, Jan 17, 2010 at 2:04 PM, Pavel Stehule
>>> wrote:
I rewrote patch so now interface for PQescapeIdentConn is same as
PQescapeStringConn
@3. I though so the
On Mon, Jan 18, 2010 at 1:52 PM, Pavel Stehule wrote:
> 2010/1/18 Robert Haas :
>> On Sun, Jan 17, 2010 at 2:04 PM, Pavel Stehule
>> wrote:
>>> I rewrote patch so now interface for PQescapeIdentConn is same as
>>> PQescapeStringConn
>>>
>>> @3. I though so the protection under incomplete multiby
2010/1/18 Robert Haas :
> On Sun, Jan 17, 2010 at 2:04 PM, Pavel Stehule
> wrote:
>> I rewrote patch so now interface for PQescapeIdentConn is same as
>> PQescapeStringConn
>>
>> @3. I though so the protection under incomplete multibyte chars are
>> enought - missing bytes are replaced by space -
On Sun, Jan 17, 2010 at 2:04 PM, Pavel Stehule wrote:
> I rewrote patch so now interface for PQescapeIdentConn is same as
> PQescapeStringConn
>
> @3. I though so the protection under incomplete multibyte chars are
> enought - missing bytes are replaced by space - like
> PQescapeStringConn does.
2010/1/16 Robert Haas :
> On Thu, Jan 14, 2010 at 8:46 PM, Robert Haas wrote:
>> I have yet to fully review the code but on a quick glance it looks
>> reasonable.
>
> On further review, it looks less reasonable. :-(
>
> The new PQescapeIdentConn function is basically a cut-up version of
> PQesca
On Thu, Jan 14, 2010 at 8:46 PM, Robert Haas wrote:
> I have yet to fully review the code but on a quick glance it looks reasonable.
On further review, it looks less reasonable. :-(
The new PQescapeIdentConn function is basically a cut-up version of
PQescapeStringInternal, which seems like a re
2010/1/15 Robert Haas :
> On Mon, Jan 11, 2010 at 6:54 AM, Pavel Stehule
> wrote:
>>> No longer applies, please rebase.
>>
>> fixed, sorry
>
my idea was:
* string
* escape_string
* escape_ident
* bytea
* escape_bytea
But I am not strong in it. Maybe this part of doc needs more love -
On Mon, Jan 11, 2010 at 6:54 AM, Pavel Stehule wrote:
>> No longer applies, please rebase.
>
> fixed, sorry
Hmm. I think that pqEscapeIdentConn should be in a separate section
of the documentation, entitled "Escaping Identifiers for Inclusion in
SQL Commands". Or else we should merge the existi
Hello
>
> No longer applies, please rebase.
>
fixed, sorry
Pavel
> Thanks,
>
> ...Robert
>
variable_escaping-fix.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
2010/1/11 Robert Haas :
> On Tue, Jan 5, 2010 at 8:23 AM, Pavel Stehule wrote:
>> 2010/1/5 Tom Lane :
>>> Robert Haas writes:
On Mon, Jan 4, 2010 at 2:51 PM, Pavel Stehule
wrote:
> I don't have a problem to write second and safe fmtId
> function (with technique used in dumputi
On Tue, Jan 5, 2010 at 8:23 AM, Pavel Stehule wrote:
> 2010/1/5 Tom Lane :
>> Robert Haas writes:
>>> On Mon, Jan 4, 2010 at 2:51 PM, Pavel Stehule
>>> wrote:
I don't have a problem to write second and safe fmtId
function (with technique used in dumputils don't need to modify
lib
2010/1/5 Tom Lane :
> Robert Haas writes:
>> On Mon, Jan 4, 2010 at 2:51 PM, Pavel Stehule
>> wrote:
>>> I don't have a problem to write second and safe fmtId
>>> function (with technique used in dumputils don't need to modify
>>> libpq), although fmtId do exactly what I need. I would to underst
Robert Haas writes:
> On Mon, Jan 4, 2010 at 2:51 PM, Pavel Stehule wrote:
>> I don't have a problem to write second and safe fmtId
>> function (with technique used in dumputils don't need to modify
>> libpq), although fmtId do exactly what I need. I would to understand
>> to behave.
> I think y
On Mon, Jan 4, 2010 at 2:51 PM, Pavel Stehule wrote:
> 2010/1/4 Tom Lane :
>> Pavel Stehule writes:
>>> I have one question. If I understand well, the function fmtId isn't
>>> multibyte safe? So why is possible to use it in pg_dump?
>>
>> pg_dump is only guaranteed to work correctly in the server
2010/1/4 Tom Lane :
> Pavel Stehule writes:
>> I have one question. If I understand well, the function fmtId isn't
>> multibyte safe? So why is possible to use it in pg_dump?
>
> pg_dump is only guaranteed to work correctly in the server encoding.
> If you force it to use a client_encoding differe
Pavel Stehule writes:
> I have one question. If I understand well, the function fmtId isn't
> multibyte safe? So why is possible to use it in pg_dump?
pg_dump is only guaranteed to work correctly in the server encoding.
If you force it to use a client_encoding different from the server's,
it migh
Hello
I talked with Hitoshi Harada, and fmtId function is safe (minimally
for Japanese case). This function working without any errors, so we
must not duplicate a code.
Pavel
2010/1/4 Pavel Stehule :
> hello
>
> 2010/1/2 Tom Lane :
>> Pavel Stehule writes:
>>> here is patch
>>
>> I looked at t
hello
2010/1/2 Tom Lane :
> Pavel Stehule writes:
>> here is patch
>
> I looked at this patch a bit, and I think the real problem with it is
> that it's not multibyte safe. You've copied backend code that is
> allowed to assume it's in a safe encoding (ie, one where multibyte
> characters can't
2010/1/2 Tom Lane :
> Pavel Stehule writes:
>> here is patch
>
> I looked at this patch a bit, and I think the real problem with it is
> that it's not multibyte safe. You've copied backend code that is
> allowed to assume it's in a safe encoding (ie, one where multibyte
> characters can't contain
2010/1/2 Tom Lane :
> Pavel Stehule writes:
>> a) print correct message and exit(1)
>
> Which part of "no, you're not doing that" wasn't clear to you?
>
> The error handling in this function should be no different from that
> in the existing escaping functions. exit(1) is completely unacceptable
Pavel Stehule writes:
> here is patch
I looked at this patch a bit, and I think the real problem with it is
that it's not multibyte safe. You've copied backend code that is
allowed to assume it's in a safe encoding (ie, one where multibyte
characters can't contain non-high-bit-set bytes). This
Pavel Stehule writes:
> a) print correct message and exit(1)
Which part of "no, you're not doing that" wasn't clear to you?
The error handling in this function should be no different from that
in the existing escaping functions. exit(1) is completely unacceptable.
regar
2009/12/30 Robert Haas :
> On Tue, Dec 29, 2009 at 3:19 PM, Pavel Stehule
> wrote:
>> here is patch
>
> The error handling in quote_literal() doesn't look right to me. The
> documentation for PQescapeStringConn says that it stores an error
> message in the conn object, but your code ignores that
On Tue, Dec 29, 2009 at 3:19 PM, Pavel Stehule wrote:
> here is patch
The error handling in quote_literal() doesn't look right to me. The
documentation for PQescapeStringConn says that it stores an error
message in the conn object, but your code ignores that and prints out
a generic message inst
hello
here is patch
pa...@postgres:5432=# \set foo 'hello world'
pa...@postgres:5432=# SELECT :'foo' AS :"foo";
hello world
-
hello world
(1 row)
Regards
Pavel
2009/12/29 Pavel Stehule :
> 2009/12/29 Tom Lane :
>> Pavel Stehule writes:
>>> 2009/12/29 Alvaro Herrera :
Can we
2009/12/29 Tom Lane :
> Pavel Stehule writes:
>> 2009/12/29 Alvaro Herrera :
>>> Can we use a trick similar to pg_dump's?
>
>> I see it - we can move function (content) fmtId from dumputils.c to libpq.
>
> This is not a good idea. pg_dump can be expected to be up-to-date with
> the backend's keyw
Pavel Stehule writes:
> 2009/12/29 Alvaro Herrera :
>> Can we use a trick similar to pg_dump's?
> I see it - we can move function (content) fmtId from dumputils.c to libpq.
This is not a good idea. pg_dump can be expected to be up-to-date with
the backend's keyword list, but libpq cannot.
Just
2009/12/29 Alvaro Herrera :
> Pavel Stehule escribió:
>> 2009/12/29 Alvaro Herrera :
>> > Pavel Stehule escribió:
>> >> 2009/12/29 Tom Lane :
>> >> > Pavel Stehule writes:
>> >> >> so we cannot simply implement quote_ident on client side :(. So we
>> >> >> have to use a real query.
>> >> >
>> >> >
Pavel Stehule escribió:
> 2009/12/29 Alvaro Herrera :
> > Pavel Stehule escribió:
> >> 2009/12/29 Tom Lane :
> >> > Pavel Stehule writes:
> >> >> so we cannot simply implement quote_ident on client side :(. So we
> >> >> have to use a real query.
> >> >
> >> >> It is acceptable for you?
> >> >
> >
2009/12/29 Alvaro Herrera :
> Pavel Stehule escribió:
>> 2009/12/29 Tom Lane :
>> > Pavel Stehule writes:
>> >> so we cannot simply implement quote_ident on client side :(. So we
>> >> have to use a real query.
>> >
>> >> It is acceptable for you?
>> >
>> > No, certainly not --- that adds a boatlo
2009/12/29 Alvaro Herrera :
> Pavel Stehule escribió:
>> 2009/12/29 Tom Lane :
>> > Pavel Stehule writes:
>> >> so we cannot simply implement quote_ident on client side :(. So we
>> >> have to use a real query.
>> >
>> >> It is acceptable for you?
>> >
>> > No, certainly not --- that adds a boatlo
Pavel Stehule escribió:
> 2009/12/29 Tom Lane :
> > Pavel Stehule writes:
> >> so we cannot simply implement quote_ident on client side :(. So we
> >> have to use a real query.
> >
> >> It is acceptable for you?
> >
> > No, certainly not --- that adds a boatload of failure conditions.
> > Just quo
2009/12/29 Tom Lane :
> Pavel Stehule writes:
>> so we cannot simply implement quote_ident on client side :(. So we
>> have to use a real query.
>
>> It is acceptable for you?
>
> No, certainly not --- that adds a boatload of failure conditions.
> Just quote it unconditionally.
ok
this function
On Dec 29, 2009, at 8:57 AM, Pavel Stehule
wrote:
Hello
I am working on new patch. I see a problem with copy quote_ident on
client side. This function call ScanKeywordLookup function.
const ScanKeyword *keyword = ScanKeywordLookup(ident,
Sc
Pavel Stehule writes:
> so we cannot simply implement quote_ident on client side :(. So we
> have to use a real query.
> It is acceptable for you?
No, certainly not --- that adds a boatload of failure conditions.
Just quote it unconditionally.
regards, tom lane
--
Sent
Hello
I am working on new patch. I see a problem with copy quote_ident on
client side. This function call ScanKeywordLookup function.
const ScanKeyword *keyword = ScanKeywordLookup(ident,
ScanKeywords,
NumSc
73 matches
Mail list logo
