Daniel Farina writes:
>
>> Finally, attached is v8. Hopefully I didn't mess things up too much.
>
> I'll give it another look-over. Do you have these in git somewhere? It
> will help me save time on some of the incremental changes.
Yes, I've just pushed my dev branch to this fork of mine:
https
Marko Kreen writes:
> On Thu, Mar 15, 2012 at 11:29:31PM +0200, Alex wrote:
>> https://github.com/a1exsh/postgres/commits/uri
>
> The point of the patch is to have one string with all connection options,
> in standard format, yes? So why does not this work:
>
> db
Alex writes:
> Marko Kreen writes:
>
>> On Thu, Mar 15, 2012 at 11:29:31PM +0200, Alex wrote:
>>> https://github.com/a1exsh/postgres/commits/uri
>>
>> The point of the patch is to have one string with all connection options,
>> in standard format, yes?
Peter Eisentraut writes:
> On tor, 2012-03-22 at 23:42 +0200, Alex wrote:
>> Okay, at last here's v9, rebased against current master branch.
>
> Attached is a patch on top of your v9 with two small fixes:
>
> - Don't provide a check target in libpq/Makefile if it
Alex writes:
> Peter Eisentraut writes:
>>
>> Attached is a patch on top of your v9 with two small fixes:
>>
>> - Don't provide a check target in libpq/Makefile if it's not
>> implemented.
>>
>> - Use the configured port number for ru
into
default prompt, unless stdout?)
Something like this:
\set PROMPT1 '%/:%o%R%# '
postgres:/path/to/output/file.txt=>
--
Regards,
Alex
PS: upon reading the docs more carefully, I guess I should have used \g
instead of \o, but still this might be not a bad feature to have.
--
Se
=#
Not sure how \pset could fit there, it might be a bit excessive.
Another idea is we could add \O and \G commands that will act like the
plain \o and \g, but will set \a and \t automatically. I mean it must
be quite often that you don't need all the decoration when you save
query resul
##' suggested further in this thread should be
also possible.
--
Regards,
Alex
[1] http://www.redmine.org/
[2] http://www.redmine.org/plugins
[3] https://github.com/diasjorge/redmine-cli
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Greg Smith writes:
> On 04/14/2012 03:02 AM, Alex wrote:
>> I didn't follow this whole thread, but have we considered Redmine[1]?
>
> It comes up every couple of years in contexts near this one, such as
> http://wiki.postgresql.org/wiki/TrackerDiscussion
Oh, I see. I
Alex writes:
> Greg Smith writes:
>
>> On 04/14/2012 03:02 AM, Alex wrote:
>>> I didn't follow this whole thread, but have we considered Redmine[1]?
>>
>> It comes up every couple of years in contexts near this one, such as
>> http://wiki.postgresql.
Jay Levitt writes:
> Alex wrote:
>> I didn't follow this whole thread, but have we considered Redmine[1]?
>
> As the resident "Ruby is shiny, let's do everything in Rails on my
> MacBook" guy, I'd like to make a statement against interest: I've
&
l tool for the task?
Given that every other existing tool likely have pissed off someone
already, I guess our best bet is writing one from scratch.
Or maybe there isn't really a need for a tracker? The core team have
managed to live without one for so long after all...
--
Regards,
Alex
[
h IIRC doesn't have any kind of reasonable database backend, which
> would be a strange choice for a project like ours :) And makes many
> things harder...
What stops us from writing a postgres backend for debbugs if it is so
brilliant on handing email and stuff?
--
Alex
--
Sent via pgs
into
shape we need (and we need a few Ruby hackers, so there's always someone
in the postgres community to fix it when it breaks, of course.)
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ion
attempts and only deals with testing the parser routine. Does it change
that?
--
Regards,
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
riting Perl: replaces the
shell script, adds $libpq_uri_regress project to Mkvcbuild.pm.
I don't have access to a win32 box unfortunately, so if anyone who does
could try this out that'd be great.
--
Regards,
Alex
diff --git a/src/interfaces/libpq/test/Makefile b/src/interfaces/libpq
Peter Eisentraut writes:
> On tor, 2012-04-19 at 00:13 +0300, Alex wrote:
>> +#!/usr/bin/env perl
>
> Don't do that. Call the script using $(PERL) from the makefile.
Thank you for the suggestion. Attached v2 does just this (while keeping
a more commonly found shebang lin
the whole "?keyword=value&..."
business.
I'll give this another look and will get back with a proposal to fix
this in form of a patch.
--
Regards,
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
karave...@mail.bg writes:
> - Цитат от Alex Shulgin (a...@commandprompt.com), на 14.05.2012 в 18:16
> -
>
>> Alex writes:
>>
>>
>> The host part in this case is empty (it is "hidden" between the "//" and
>> the following &quo
Alex Shulgin writes:
>
> Upon closer inspection of the issue I came to believe that the proper
> fix is to drop support for special treatment of "host part" starting
> with slash altogether.
>
> Attached is a patch to do that.
Well, I understand I might be asking
Peter Eisentraut writes:
> On mån, 2012-05-14 at 18:16 +0300, Alex Shulgin wrote:
>> Upon closer inspection of the issue I came to believe that the proper
>> fix is to drop support for special treatment of "host part" starting
>> with slash altogether.
>&g
iginal intent was to not error out on any extra parameters from
JDBC or other existing URI implementations. The example of a possible
typo in sslmode=require clearly demonstrates that this was not
a well-thought decision.
Anyway, I can see you've already sorted this out.
--
Alex
--
Sent via pgsq
happen? Currently
we are forced to poll the connection, which means that we'll be checking
for a NOTIFY every time we have new data.
That just doesn't make sense.
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
The situation is like that:
[19:24] Who can help with file system level backup?
[19:24] Press_Enter: shut down postgres, tar the data dir
[19:25] Press_Enter: apparently filesystem snapshots might work as well
[19:25] Press_Enter: you're supposed to use pg_dumpall
[19:25] KL, my question is so
pens to scratch yours, more the merrier.
-alex
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
ard compatibility (to perl 5.4 for example)
or not. Or whether I even care about backward compatibility. I'll remove
it in next release, I suppose.
-alex
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
At least they aren't on my machine. Intrinsically, this
module needs to know a little bit more about pgsql internals (such as
TupleDesc definition) than just something that uses libpq...
If I'm wrong, please correct me.
-alex
---(end of broadcast)---
TIP 8: explain analyze is your friend
- make
install won't install by default. I'll add proper path to makefile for
next release (sooner than 3 years this time ;)
-alex
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "
> or selectX, but other than that it seems to work. I'll be grabbing the
> update to test soon.
'do' seems to work for me. What happens for you?
I put a version of code with a bit more fixes from comments onlist to
www.pilosoft.com/PgSPI/DBD-PgSPI-0.03pre.tar.gz
Please downlo
e layer as well as in-DB. That way I only need to
> write the logic once.
Yep, that's kind of was the point, making postgresql itself a middleware
server. Make perl stored procedures take serialized objects and return
serialized objects back.
-alex
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
distribution of postgres - we'd have to reinvent it in a clean room fashion.
Actually, its both GPL and Artistic license - identical to DBD::Pg (where
most of the code is taken from).
I don't think this needs to be in core distribution - much like DBD::Pg
doesn't need to be there ei
r-side stored procedure out of it in a minute without any changes to
the code.
For quick access from trusted code, spi_exec should just do fine.
-alex
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
it on server side.
Besides the fact is that they have to download DBI to get *anywhere* in
the first place ;0
-alex
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Mon, 6 Dec 2004, Michael Fuhr wrote:
> On Mon, Dec 06, 2004 at 02:34:33PM -0500, [EMAIL PROTECTED] wrote:
> >
> > For quick access from trusted code, spi_exec should just do fine.
>
> BTW, does stock PL/Perl have functions for escaping identifiers,
> strings, and binary strings?
non-DBI? no.
t to make DBI itself
Safe-safe. Probably it would require starting with DBI::PurePerl (non-XS
version) and adding a mode that would disable all unSafe activity (such as
file operations etc etc)...
-alex
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
there are a few questions.
1) How portable is it ?
2) What implications does it have on the postgres
backend ?
This could be useful in some situations (like
logtables , where I don't need instant inserts or updates..)
Thanks
Alex
On Mon, Mar 7, 2016 at 11:32 PM, Andres Freund wrote:
> Hi,
>
> Per the new valgrind animal we get:
>
>
> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=skink&dt=2016-03-08%2004%3A22%3A00
> 2016-03-08 05:56:05.566 UTC [56de6971.723:5] LOG: statement: select
> plperl_sum_array('{}');
> ==1827== In
, disallows
leading zero, empty string, or non-digit chars. Error messages looks good.
Marking this Ready for Committer.
--
Alex
The new status of this patch is: Ready for Committer
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
suck
performance out particularly for rotating disks.
Rotating disks is not a problem - you can always raid them and etc. 8k
allocation per relation once per half an hour that is the problem. Seq
scan is this way = random scan...
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
Hello!
Does parallel secscan works in plpgsql?
--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
gregate (cost=288697.59..288847.74 rows=15015 width=28)
Group Key: test.a, test.b, test.c, test.d, test.e
-> Seq Scan on test (cost=0.00..163696.15 rows=1115
width=20)
So as we can see parallel secscan doesn't works in plpgsql and sql functions.
Can somebody explains m
On 16.09.2016 16:50, Amit Kapila wrote:
On Fri, Sep 16, 2016 at 6:57 PM, Alex Ignatov wrote:
No it doesn't.
Paralleling neither sql function nor plpgsql:
Here is example :
ipdr=> show max_worker_processes ;
max_worker_processes
--
128
(1 row)
ip
On 18.09.2016 06:54, Amit Kapila wrote:
On Fri, Sep 16, 2016 at 8:48 PM, Alex Ignatov wrote:
On 16.09.2016 16:50, Amit Kapila wrote:
Can you try by setting force_parallel_mode = off;? I think it is
sending the whole function execution to worker due to
force_parallel_mode.
No changes
Hi Alexander!
I've missed your reply, since proposal submission deadline have passed last
Monday and I didn't check hackers mailing list too frequently.
(1) It seems that starting new subtransaction at step 4 is not necessary.
We can just gather all error lines in one pass and at the end of input
Greetings pgsql-hackers,
I am a GSOC student this year, my initial proposal has been discussed
in the following thread
https://www.postgresql.org/message-id/flat/7179F2FD-49CE-4093-AE14-1B26C5DFB0DA%40gmail.com
Patch with COPY FROM errors handling seems to be quite finished, so
I have started thi
On Fri, Jun 30, 2017 at 3:35 PM, Pavel Stehule wrote:
>
>
> 2017-06-30 14:23 GMT+02:00 Alex K :
>>
>> Thus, it results in a ~60% performance boost per each x2 multiplication of
>> parallel processes, which is consistent with the initial estimation.
>>
>
> t
Greetings pgsql-hackers,
I have completed the general infrastructure for parallel COPY FROM execution,
consisting of Main (master) process and multiple BGWorkers connected with master
using a personal message query (shm_mq).
Master process does:
- Dynamic shared memory allocation with parallel st
Hi pgsql-hackers,
Thank you again for all these replies. I have started working under this
project
and learnt a lot of new stuff last month, so here are some new thoughts
about
ERRORS handling in COPY. I decided to stick to the same thread, since it
has a neutral subject.
(1) One of my mentors--A
m it.>
> When recovery_conf is there, starting of a replica could become a real
> problem, especially if restore_command is slow.>
> Is it possible to change this behavior somehow? First look into
> pg_xlog and only if file is missing or "corrupted" call
> restore_command.>
>
> Regards,
> ---
> Alexander Kukushkin
Sincerely,
Alex
finitely sooner or later get this Fatal
on recovery .
With this patch we try to get rid of AccessEclusiveLock applied on standby
while we have active statement on it.
--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-h
On Tue, Feb 25, 2014 at 6:56 AM, Sergey Burladyan wrote:
> It looks like I found the problem, Perl use reference count and something that
> is called "Mortal" for memory management. As I understand it, mortal is free
> after FREETMPS. Plperl call FREETMPS in plperl_call_perl_func() but after it,
On Wed, Mar 5, 2014 at 12:22 PM, Alvaro Herrera
wrote:
> Can I bug you into verifying what supported releases need this patch,
> and to which does it backpatch cleanly? And if there's any to which it
> doesn't, can I further bug you into providing one that does?
Sure! Not bugging at all. I'll d
On Wed, Mar 5, 2014 at 12:55 PM, Alex Hunsaker wrote:
> On Wed, Mar 5, 2014 at 12:22 PM, Alvaro Herrera
> wrote:
>
>> Can I bug you into verifying what supported releases need this patch,
>> and to which does it backpatch cleanly? And if there's any to which it
>>
ad of 'extension'
which sounds like some MS-DOS thingy, but after briefly grepping the
docs I can see that both words are used in this context already (and the
ratio is not in favor of my choice of wording.)
Other than that the patch looks good.
--
Alex
[1] http://archives.postgresql.org
On Thu, Feb 9, 2012 at 03:21, Christoph Berg wrote:
> Hi,
>
> we have a database that is storing strings in various encodings (and
> non-encodings, namely the arbitrary byte soup [ ... ]
> For this reason, the database uses
> sql_ascii encoding
> ...snip...
> In sql_ascii databases, utf_e2u does
On Thu, Feb 9, 2012 at 11:30, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Tom Lane's message of jue feb 09 12:17:59 -0300 2012:
>> FWIW that script is throwing a warning here:
>> Use of assignment to $[ is deprecated at
>> /pgsql/source/HEAD/src/tools/check_keywords.pl line 19.
>
recognized and being ignored. Not sure if plain fprintf to stderr is
accepted practice for libpq, please correct if you have better idea.
--
Regards,
Alex
*** a/src/interfaces/libpq/fe-connect.c
--- b/src/interfaces/libpq/fe-connect.c
***
*** 282,287 static const PQEnvironmentOptio
Florian Weimer writes:
> * Alex Shulgin:
>
>> Yeah, this is really appealing, however how do you tell if the part
>> after the last slash is a socket directory name or a dbname? E.g:
>>
>> psql postgres:///path/to/different/socket/dir(default dbnam
he `postgres` prefix, as opposed to
>`postgresql` for the reasons stated on an earlier thread [3]. In my
>opinion the best way to move forward is to support them both.
The updated v4 version of the patch does cover this:
http://archives.postgresql.org/pgsql-hackers/2012-02/ms
igured that adding this right into src/interfaces/libpq is polluting
the source dir, so I've used src/test instead.
Attached v6 adds src/test/uri directory complete with the test script,
expected output file and a Makefile which responds to installcheck.
README file also included.
--
Alex
s://@host
postgres://host:/
and, taking approach to the extreme:
postgres://:@:
This specifies empty user, password, host and port, and looks really
funny. I've added (actually revived) some checks to forbid setting
empty URI parts where it doesn't make much sense.
Finally, attached is v8. Hopefully I didn't mess things up too much.
--
Regards,
Alex
binaKreQKSDSW.bin
Description: libpq-uri-v8.patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alex writes:
> Marko Kreen writes:
>
>> On Thu, Mar 15, 2012 at 11:29:31PM +0200, Alex wrote:
>>> https://github.com/a1exsh/postgres/commits/uri
>>
>> The point of the patch is to have one string with all connection options,
>> in standard format, yes?
Heikki Linnakangas writes:
> On 22.03.2012 23:42, Alex wrote:
>> Okay, at last here's v9, rebased against current master branch.
>
> Some quick comments on this patch:
Heikki, thank you for taking a look at this!
> I see a compiler warning:
> fe-connect.c: In funct
SQL statements for various purposes, e.g. for
dependency analysis.
This is a misfeature for the benefit of edit-lazy users only.
-- Alex
re_raw_read()
can't know about IdleTransactionCancelPending and I'm not sure what
would be the best way to let it see that (is it too much of a shortcut
anyway?)
--
Alex
[1] http://www.postgresql.org/message-id/1262268211.19367.10736.camel@ebony
[2] http://www.postgresql.org/message-id/538dc
Andres Freund writes:
>
> On 2014-11-15 00:11:36 +0300, Alex Shulgin wrote:
>> After reading up through archives on the two $subj related TODO items
>> I'm under impression that the patches[1,2] didn't make it mainly because
>> of the risk of breaking SSL inte
Andres Freund writes:
> On 2014-11-15 00:11:36 +0300, Alex Shulgin wrote:
>> After reading up through archives on the two $subj related TODO items
>> I'm under impression that the patches[1,2] didn't make it mainly because
>> of the risk of breaking SSL interna
the client when in
ProcessInterrupts() and DoingCommandRead is true. I think[1] it was
expected to be delivered instantly, but actually the client (psql) only
displays it after sending the next statement.
While I'm reading on FE/BE protocol someone might want to share his
wisdom on this subject.
read from it
and no attempt is made to verify this on startup. This might be not a
very useful check since if the file is not missing, but corrupted the
check doesn't buy you much. (I am likely kicking a dead horse here.)
Thank you.
--
Alex
[1] http://svana.org/kleptog/pgsql/pgfsck.html
--
rectly.
I would try to apply patches for older branches if there is consensus
that we really need this patch and we want to back-patch it.
Thanks.
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dag-Erling Smørgrav writes:
> Alex Shulgin writes:
>> * The patch works as advertised, though the only way to verify that
>> connections made with the protocol disabled by the GUC are indeed
>> rejected is to edit fe-secure-openssl.c to only allow specific TLS
&
mitFest entry is the latest
on the subject, right?
https://commitfest.postgresql.org/action/patch_view?id=1293
Should/may I move it to the next Open fest?
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dag-Erling Smørgrav writes:
> Alex Shulgin writes:
>> I can do that too, just need a hint where to look at in libpq/psql to
>> add the option.
>
> The place to *enforce* the option is src/interfaces/libpq/fe-secure.c
> (look for SSLv23_method() and SSL_CTX_set_optio
GET_XID;
>> +else if (recovery_target_name[0])
>> +recovery_target = RECOVERY_TARGET_NAME;
>> +else if (recovery_target_time != 0)
>> +recovery_target = RECOVERY_TARGET_TIME;
>> +else
>> +recovery_target = RECOVERY_TAR
Alex Shulgin writes:
>
>>> > * Why do you include xlog_internal.h in guc.c and not xlog.h?
>>
>>> we actually need both but including xlog_internal.h also includes xlog.h
>>> i added xlog.h and if someone things is enough only putting
>>> xlog_i
has a number of advantages as a method,
> the main one being that recovery.conf is unlikely to be overwritten by
> the contents of the backup.
>
> HOWEVER, there's a clear out for this with conf.d. If we enable conf.d
> by default, then we can simply put recovery settings in conf.d, and
> since that specific file (which can have whatever name the user chooses)
> will not be part of backups, it would have the same advantage as
> recovery.conf, without the drawbacks.
>
> Discuss?
Well, I don't readily see how conf.d is special with regard to base
backup, wouldn't you need to exclude it explicitly still?
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
eplication replication=true
fallback_application_name=walreceiver",
conninfo);
A patch to fix this welcome?
--
Alex
PS: I wrote the original URI parser used in libpq.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
I just spotted this missing check.
The second one is a self-contained fix, but the third one which is the
actual patch depends on the second one, because it specifies the dbname
keyword two times: first to parse the conninfo/URI, then to override any
dbname provided by the user with "replicatio
ut if instead of removing the
trigger file upon successful recovery the server would set
standby_mode=off, that would also work.
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
argue that it's not
> required for PITR either, provided that we can use the auto.conf method.
>
> Before I go into my ideas, though, what does the current patch do
> regarding non-replication PITR?
It removes that $PGDATA/standby.enable trigger file it relies on to
start the P
; OK, and that's required for replication too? I'm OK with that if it
> gets the patch in.
In the current form of the patch, yes. Thought I don't think I like it.
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alex Shulgin writes:
> Heikki Linnakangas writes:
>>>
>>> It appears that replication connection doesn't support URI but only the
>>> traditional conninfo string.
>>>
>>> src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:
Heikki Linnakangas writes:
> On 11/24/2014 06:05 PM, Alex Shulgin wrote:
>> The first patch is not on topic, I just spotted this missing check.
>
>> *** a/src/interfaces/libpq/fe-connect.c
>> --- b/src/interfaces/libpq/fe-connect.c
>> *** conninfo
t different.
Great. Are you looking at the actual replication URI patch? Or should
I add it to commitfest so we don't lose track of it?
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
changes. It's necessary to
> say "connection string or URI" everywhere, the URI format is just one
> kind of a connection string. I also edited the code that builds the
> keyword/value array, to make it a bit more readable.
Yay, many thanks! :-)
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
o wait before 9.4 is released?
Thanks.
--
Alex
[1]
http://dba.stackexchange.com/questions/83600/postgresql-create-index-memory-requirement
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane writes:
> Stephen Frost writes:
>> * Alex Shulgin (a...@commandprompt.com) wrote:
>>> Tom,
>>>
>>> First of all, thanks for your help on IRC last time with that CREATE
>>> INDEX memory consumption problem.
>
>> Doubt it was Tom,
Andrew Gierth writes:
>>>>>> "Alex" == Alex Shulgin writes:
>
> > Tom Lane writes:
> >> Must've been my evil twin.
>
> Alex> Sorry, I must be under false impression that RhodiumToad is
> Alex> *your* nick on #postgresql
Alex Shulgin writes:
>>>
>>> I can do that too, just need a hint where to look at in libpq/psql to
>>> add the option.
>>
>> The place to *enforce* the option is src/interfaces/libpq/fe-secure.c
>> (look for SSLv23_method() and SSL_CTX_set_option
tead of drop support of it
entirely?
--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Dec 8, 2010 at 14:15, Oleg Bartunov wrote:
> On Wed, 8 Dec 2010, David E. Wheeler wrote:
>
>> On Dec 8, 2010, at 8:13 AM, Oleg Bartunov wrote:
>>
>>> adding utf8::decode($_[0]) solves the problem:
>> Hrm. Ideally all strings passed to PL/Perl functions would be decoded.
>
> yes, this is wh
On Thu, Dec 16, 2010 at 20:24, David E. Wheeler wrote:
> On Dec 16, 2010, at 6:39 PM, Alex Hunsaker wrote:
>
>> You might argue this is a bug with URI::Escape as I *think* all uri's
>> will be utf8 encoded. Anyway, I think postgres is doing the right
>> thing here
On Fri, Dec 17, 2010 at 08:30, David Fetter wrote:
> On Thu, Dec 16, 2010 at 07:24:46PM -0800, David Wheeler wrote:
>> On Dec 16, 2010, at 6:39 PM, Alex Hunsaker wrote:
>>
>> > Grr that should error out with "Invalid server encoding", or worst
>> >
On Fri, Dec 17, 2010 at 11:51, Alex Hunsaker wrote:
> Also note this is just a simple test case, perl *could* elect to store
> completely ascii strings internally as utf8. In those cases we still
Erm... not ascii I mean bytes >127
--
Sent via pgsql-hackers mailing list (pgsq
On Fri, Dec 17, 2010 at 22:32, David Christensen wrote:
>
> On Dec 17, 2010, at 7:04 PM, David E. Wheeler wrote:
>
>> On Dec 16, 2010, at 8:39 PM, Alex Hunsaker wrote:
>>
>>>> No, URI::Escape is fine. The issue is that if you don't decode text to
>>&
On Fri, Dec 17, 2010 at 18:22, David E. Wheeler wrote:
> On Dec 17, 2010, at 5:04 PM, David E. Wheeler wrote:
>
>>> see? Either uri_unescape() should be decoding that utf8() or you need
>>> to do it *after* you call uri_unescape(). Hence the maybe it could be
>>> considered a bug in uri_unescape(
On Fri, Dec 17, 2010 at 18:04, David E. Wheeler wrote:
> On Dec 16, 2010, at 8:39 PM, Alex Hunsaker wrote:
> Yeah. So I just wrote and tested this function on 9.0 with Perl 5.12.2:
>
> CREATE OR REPLACE FUNCTION perlgets(
> TEXT
> ) RETURNS TABLE(length INT, is_u
On Sat, Dec 18, 2010 at 20:29, David E. Wheeler wrote:
> On Dec 17, 2010, at 9:32 PM, David Christensen wrote:
> latin=# SELECT * FROM perlgets('“hello”');
> length │ is_utf8
> ┼─
> 11 │ f
>
> (Yes I used Latin-1 curly quotes in that last example).
Erm, latin1 do
On Sat, Dec 18, 2010 at 20:29, David E. Wheeler wrote:
> ...
> I would argue that it should output the same as the first example. That is,
> PL/Perl should have decoded the latin-1 before passing the text to the Perl
> function.
Yeah, I don't think you will find anyone who disagrees :) PL/TCL
On Sun, Dec 19, 2010 at 21:00, David Christensen wrote:
>
> On Dec 19, 2010, at 2:20 AM, Alex Hunsaker wrote:
>
>> With the attached we:
>> - for function arguments, convert (using pg_do_encoding_conversion) to
>> utf8 from the current database encoding.
>
> How
1 - 100 of 654 matches
Mail list logo
