2011/6/15 Pavel Stehule :
> Hello
>
> I try to apply your patch, but it is finished with some failed hinks.
>
> Please, can you refresh your patch
>
> Regards
>
> Pavel
>
> [pavel@nemesis postgresql]$ patch -p1 < pghba.patch
> patching file src/backend/libpq/hba.c
> Hunk #1 succeeded at 45 (offset
On 29 October 2010 09:59, Brendan Jurd wrote:
> On 18 October 2010 01:19, Tom Lane wrote:
>> Brendan Jurd writes:
>>> On 17 October 2010 09:59, Tom Lane wrote:
Good point. Maybe the correct fix is to remember whether each token was
quoted or not, so that keyword detection can be done
Brendan Jurd wrote:
> On 26 February 2011 18:06, Bruce Momjian wrote:
> >
> > Any progress on this?
> >
>
> I ended up doing most of the work, but never got around to finishing
> it off. Thanks for the reminder, though. I'll get that one ready and
> drop it onto the next CF.
Added to TODO:
On Sat, Feb 26, 2011 at 10:57, Brendan Jurd wrote:
> On 26 February 2011 18:06, Bruce Momjian wrote:
>>
>> Any progress on this?
>>
>
> I ended up doing most of the work, but never got around to finishing
> it off. Thanks for the reminder, though. I'll get that one ready and
> drop it onto the
On 26 February 2011 18:06, Bruce Momjian wrote:
>
> Any progress on this?
>
I ended up doing most of the work, but never got around to finishing
it off. Thanks for the reminder, though. I'll get that one ready and
drop it onto the next CF.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (p
Any progress on this?
---
Brendan Jurd wrote:
> On 18 October 2010 01:19, Tom Lane wrote:
> > Brendan Jurd writes:
> >> On 17 October 2010 09:59, Tom Lane wrote:
> >>> Good point. ?Maybe the correct fix is to remember whe
On 18 October 2010 01:19, Tom Lane wrote:
> Brendan Jurd writes:
>> On 17 October 2010 09:59, Tom Lane wrote:
>>> Good point. Maybe the correct fix is to remember whether each token was
>>> quoted or not, so that keyword detection can be done safely after the
>>> initial lexing. I still think
Brendan Jurd writes:
> On 17 October 2010 09:59, Tom Lane wrote:
>> Good point. Maybe the correct fix is to remember whether each token was
>> quoted or not, so that keyword detection can be done safely after the
>> initial lexing. I still think that the current method is impossibly
>> ugly ...
On 17 October 2010 09:59, Tom Lane wrote:
> Brendan Jurd writes:
>> At the time that next_token gets called, we have no way of knowing
>> which field is currently being tokenised, at least not without doing
>> some serious rearrangement of hba.c, so that it tokenises and then
>> parses one token
Brendan Jurd writes:
> Full answer: The problem is that pg_hba.conf doesn't have a fixed
> structure. Each line can be 4, 5 or 6 fields (not including the final
> 'options' field) long, and which of these structures apply to any
> given line isn't decided until parse_hba_line goes to work on it.
Alvaro Herrera writes:
> Excerpts from Brendan Jurd's message of sáb oct 16 11:53:31 -0300 2010:
>> Try New and Improved This Message (tm), now with attachment!
> Hmm. Would it be possible to list keywords _applicable_ to each field,
> and have these passed down to next_token by the caller inst
On 17 October 2010 02:27, Alvaro Herrera wrote:
> Hmm. Would it be possible to list keywords _applicable_ to each field,
> and have these passed down to next_token by the caller instead? This
> seems backwards, but I'm not sure if the other way is really workable.
>
Short answer: I don't think
Excerpts from Brendan Jurd's message of sáb oct 16 11:53:31 -0300 2010:
> On 17 October 2010 01:52, Brendan Jurd wrote:
> > Per the above discussion, I've prepared a patch to make keywords in
> > pg_hba.conf field-specific.
>
> Try New and Improved This Message (tm), now with attachment!
Hmm. W
On 17 October 2010 01:52, Brendan Jurd wrote:
> Per the above discussion, I've prepared a patch to make keywords in
> pg_hba.conf field-specific.
>
Try New and Improved This Message (tm), now with attachment!
Cheers,
BJ
*** a/src/backend/libpq/hba.c
--- b/src/backend/libpq/hba.c
***
On 13 October 2010 00:28, Fujii Masao wrote:
> On Sat, Oct 9, 2010 at 11:13 AM, Brendan Jurd wrote:
>> I understand that 'replication' is a keyword as far as the database
>> name is concerned, but I was surprised to find that it was treated as
>> a keyword in the username field also. I had a loo
On Sat, Oct 9, 2010 at 11:13 AM, Brendan Jurd wrote:
> I understand that 'replication' is a keyword as far as the database
> name is concerned, but I was surprised to find that it was treated as
> a keyword in the username field also. I had a look in
> src/backend/libpq/hba.c, and next_token() ap
On Fri, Oct 8, 2010 at 10:13 PM, Brendan Jurd wrote:
> One of the speedbumps I hit when setting up HS+SR was naming the user
> the slave would connect as for streaming replication. At first I
> picked 'replication', which seemed quite natural to me (and I don't
> doubt will seem natural to others
Hi folks,
One of the speedbumps I hit when setting up HS+SR was naming the user
the slave would connect as for streaming replication. At first I
picked 'replication', which seemed quite natural to me (and I don't
doubt will seem natural to others as well).
When I started up the slave, I got this
18 matches
Mail list logo
