I don't know what the best solution is here. The BOM encoded as UTF-8
is valid data in other encodings. Of course, there is your point that
such data cannot be at the start of an SQL command.
Is the UTF-8 BOM ( EF BB BF ) actually valid data in any other multi-byte
encoding (other than
Itagaki Takahiro wrote:
I've reviewed your patch. The rough approach looks fine,
but I have some comments about function declarations and coding style.
Thank you for taking the time!
I think I addressed all the shortcomings you mentioned with
the attached patches. I fixed the { alignment; I am
Alex Hunsaker wrote:
Find attached a incremental diff with the following changes:
-get rid of operation argument to InitResultRelInfo, its unused now
Missed that one. Thanks.
-add some asserts to make sure places we use subplanstate now that it
can be null
(*note* AFAICT its a cant happen,
Hi,
Pavel Stehule pavel.steh...@gmail.com writes:
I am sending actualised patch.
I've volunteered to review this patch, and before getting to read code
and documentation, then to test it, I have some more general question.
The idea to add support for typmods in function signatures came from
I think it would better to add an explicit isencrypted parameter to
the check_password_hook function, rather than require the module to do
isMD5 on the password. Any imaginable check hook will need to know if
the password is in MD5 format, and the backend already knows it (because
it already did
Heikki Linnakangas wrote:
I think it would better to add an explicit isencrypted parameter to
the check_password_hook function, rather than require the module to do
isMD5 on the password. Any imaginable check hook will need to know if
the password is in MD5 format, and the backend already
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane replied:
Is there any chance we can raise the default geqo_threshold from
its current default of 12?
We were over that just a few months ago.
Tom, that was
Itagaki Takahiro wrote:
Multi-byte scripts
without encoding are always dangerous whether BOM is present or not.
I'd say we can always throw an error when we find queries that contain
multi-byte characters if no prior encoding declaration.
You will break a gazillion scripts that today
George Gensure wer...@gmail.com writes:
There's some tricky stuff in here to say the least. Doesn't look like
param names are kept anywhere past the parser - gonna have to have it
follow through a bunch of functions to reach
parse_(fixed|variable)_parameters. The p_post_columnref_hook you
Dimitri Fontaine dfonta...@hi-media.com writes:
The idea to add support for typmods in function signatures came from the
need to have more than one anyelement at a time in a function, and Pavel
proposed that we spell that anyelement(0) and anyelement(1) e.g.
Is that how we want to solve it?
Greg Sabino Mullane g...@turnstep.com writes:
Perhaps you mean the discussion from
July 6, 2009 started by Robert Haas? That was approximately 8000
messages ago, and no consensus was reached that I could find.
Precisely.
So I'd like to respectfully ask the hackers to consider raising the
Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
Program received signal SIGSEGV, Segmentation fault.
0x0819368b in route_tuple_to_child (parent_relation=0xb5d93040,
tuple=0x873b08c, hi_options=0, parentResultRelInfo=0x871e204) at copy.c:1821
1821
Emmanuel Cecchet m...@asterdata.com writes:
Tom Lane wrote:
This looks like the patch is trying to create a data structure in a
memory context that's not sufficiently long-lived for the use of the
structure. If you do this in a non-cassert build, it will seem to
work, some of the time, if
2009/11/17 Tom Lane t...@sss.pgh.pa.us:
Dimitri Fontaine dfonta...@hi-media.com writes:
The idea to add support for typmods in function signatures came from the
need to have more than one anyelement at a time in a function, and Pavel
proposed that we spell that anyelement(0) and anyelement(1)
Are there any plans to (is anybody working on) implement better
timezone support in postgresql
for 8.5 ? Specifically, store the timezone info -instead of just the
timestamp as UTC ?
http://wiki.postgresql.org/wiki/Todo#Dates_and_Times
Hernán J. González
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
Emmanuel Cecchet m...@asterdata.com writes:
Tom Lane wrote:
This looks like the patch is trying to create a data structure in a
memory context that's not sufficiently long-lived for the use of the
structure. If you do this in a non-cassert build, it will seem to
work,
Robert Haas robertmh...@gmail.com wrote:
On Mon, Nov 16, 2009 at 11:07 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Tom Lane wrote:
I agree with Heikki that it would be better not to commit as long
as any clear showstoppers remain unresolved.
I agree that it would be better not
On Tue, Nov 17, 2009 at 10:21 AM, hernan gonzalez hgonza...@gmail.com wrote:
Are there any plans to (is anybody working on) implement better
timezone support in postgresql
for 8.5 ? Specifically, store the timezone info -instead of just the
timestamp as UTC ?
Peter Eisentraut pete...@gmx.net writes:
I think I could support using the presence of the BOM as a fall-back
indicator of encoding in absence of any other declaration. It seems to
me, however, that the description above ignores the existence of
encodings other than SQL_ASCII and UTF8.
Yeah.
On Tue, Nov 17, 2009 at 03:54, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
Also, after reading through the previous threads; it was not
immediately obvious that you dealt with
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00566.php by
only allowing selects or values at the
Emmanuel Cecchet m...@asterdata.com writes:
Actually the list is supposed to stay around between statement
executions. You don't want to restart with a cold cache at every
statement so I really want this structure to stay in memory at a more
global level.
Cache? Why do you need a cache
Robert Haas robertmh...@gmail.com writes:
One random thought - I am not aware that we currently have a time
zone type in which to store a time zone in. Is there any value in
having such a thing vs. just using varchar?
The main potential advantage seems to be faster lookup of the zone's
Tom Lane wrote:
Emmanuel Cecchet m...@asterdata.com writes:
Actually the list is supposed to stay around between statement
executions. You don't want to restart with a cold cache at every
statement so I really want this structure to stay in memory at a more
global level.
Cache? Why
On Mon, Nov 16, 2009 at 9:56 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Sergey Konoplev escribió:
I tried to get locks with this queries
Did you try pg_locks?
I tried monitor locks with pgrowlocks. Isn't it better way? If it
isn't what points should I pay attention with pg_lock?
Can you show us the non-commented settings from your postgresql.conf?
Working postgresql.conf http://pastie.org/702748
Can you show us what the vmstat output looks like when everything is
running normally? It looks like the blocks out are pretty high, but I
don't know how that compares to
On Mon, Nov 16, 2009 at 10:17 PM, Andres Freund and...@anarazel.de wrote:
On Wednesday 11 November 2009 18:50:46 Sergey Konoplev wrote:
Hello community,
Second time after migration 8.3.7 -- 8.4.1 I was caught by this
problem. Migration was 8 days ago.
(note, I never seen such situation on
Emmanuel Cecchet m...@asterdata.com writes:
Tom Lane wrote:
Cache? Why do you need a cache for COPY?
Actually the cache is only activated if you use the partitioning option.
It is just a list of oids of child tables where tuples were inserted.
Umm ... why is that useful enough to be
Hi,
The attached patch adds support for DO clause in plpythonu. It was
heavily inspired by the plperl and plpgsql inline handler code.
I couldn't figure out how to get added files to show in git diff so the
two files that this patch adds: expected/plpython_do.out and
Valtonen, Hannu wrote:
I couldn't figure out how to get added files to show in git diff ...
git add new files
git add -u # to include modified files in the index
git diff --cached
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list
On tis, 2009-11-17 at 09:31 +0900, Itagaki Takahiro wrote:
Peter Eisentraut pete...@gmx.net wrote:
OK, I think the consensus here is:
- Eat BOM at beginning of file (as you implemented)
- Only when client encoding is UTF-8 -- please fix that
Are they AND condition? If so, this patch
On tis, 2009-11-17 at 00:59 -0800, Chuck McDevitt wrote:
Or is there a plan to read and convert the UTF-16 or UTF-32 to UTF-8,
so psql and PostgreSQL understand it?
(BTW, that would actually be nice on Windows, where UTF-16 is common).
Well, someone could implement UTF-16 or UTF-whatever as
-Original Message-
From: Peter Eisentraut [mailto:pete...@gmx.net]
Sent: Tuesday, November 17, 2009 9:05 AM
To: Chuck McDevitt
Cc: Itagaki Takahiro; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] UTF8 with BOM support in psql
On tis, 2009-11-17 at 00:59 -0800, Chuck McDevitt
Peter Eisentraut wrote:
On tis, 2009-11-17 at 00:59 -0800, Chuck McDevitt wrote:
Or is there a plan to read and convert the UTF-16 or UTF-32 to UTF-8,
so psql and PostgreSQL understand it?
(BTW, that would actually be nice on Windows, where UTF-16 is common).
Well, someone could
-Original Message-
From: Andrew Dunstan [mailto:and...@dunslane.net]
Sent: Tuesday, November 17, 2009 9:15 AM
To: Peter Eisentraut
Cc: Chuck McDevitt; Itagaki Takahiro; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] UTF8 with BOM support in psql
Peter Eisentraut wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/11/17 Tom Lane t...@sss.pgh.pa.us:
If the only immediate benefit we'd get is multiple anyelement types,
I think we'd be much better advised to just create a few separate
types for that. Function typmods are a big can of worms and we should
Andrew Dunstan and...@dunslane.net writes:
Peter Eisentraut wrote:
Well, someone could implement UTF-16 or UTF-whatever as client encoding.
But I have not heard of any concrete proposals about that.
Doesn't the nul byte problem make that seriously hard?
Just about impossible. It would
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Peter Eisentraut wrote:
Well, someone could implement UTF-16 or UTF-whatever as client encoding.
But I have not heard of any concrete proposals about that.
Doesn't the nul byte problem make that seriously hard?
2009/11/17 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/11/17 Tom Lane t...@sss.pgh.pa.us:
If the only immediate benefit we'd get is multiple anyelement types,
I think we'd be much better advised to just create a few separate
types for that. Function typmods
Andrew Dunstan and...@dunslane.net writes:
Well, it might be a good idea to provide at least some support in libpq.
Making each client do it from scratch seems a bit inefficient.
Encoding conversion seems far outside libpq's charter, and as for
from scratch there are other libraries for that.
Pavel Stehule pavel.steh...@gmail.com writes:
2009/11/17 Tom Lane t...@sss.pgh.pa.us:
There are other issues but these are the ones I think we'd need to
resolve before not after putting in function typmods. Â It'd be
extremely painful and non-backwards-compatible to change our minds
later
2009/11/17 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/11/17 Tom Lane t...@sss.pgh.pa.us:
There are other issues but these are the ones I think we'd need to
resolve before not after putting in function typmods. It'd be
extremely painful and
Sergey Konoplev escribió:
On Mon, Nov 16, 2009 at 9:56 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Sergey Konoplev escribió:
I tried to get locks with this queries
Did you try pg_locks?
I tried monitor locks with pgrowlocks. Isn't it better way? If it
isn't what points
Pavel Stehule pavel.steh...@gmail.com writes:
2009/11/17 Tom Lane t...@sss.pgh.pa.us:
My point is that if we release 8.5 with these semantics (which as far
as I can tell were not designed, but just fell out of what made for the
shortest patch) then we'll be stuck with them thereafter.
We
Hi,
I'm reviewing your patch. The patch applies without problems and the
feature works as advertised. I have yet to look at the code in detail,
but it looks sane and seems to work. However, this looks like a mistake:
partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
or am
On Thu, Nov 12, 2009 at 5:54 AM, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
I added psql and pg_dump support to Partitioning Syntax patch.
Paritioning information can be retrieved with a new system function
pg_get_partitiondef(parentRelid). Both psql and pg_dump use it.
i haven't
2009/11/17 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/11/17 Tom Lane t...@sss.pgh.pa.us:
My point is that if we release 8.5 with these semantics (which as far
as I can tell were not designed, but just fell out of what made for the
shortest patch) then
Tom Lane escribió:
George Gensure wer...@gmail.com writes:
I've put together a small patch to provide a schema name in an fk
violation in deference to the todo item Report the schema along table
name in a referential failure error message
This is not the way forward; if it were, we would
Hello,
this small patch add missing USING clause to OPEN FOR EXECUTE statement
+ cleaning part of exec_stmt_open function
see http://archives.postgresql.org/pgsql-hackers/2009-11/msg00713.php
Regards
Pavel Stehule
*** ./doc/src/sgml/plpgsql.sgml.orig 2009-11-13 23:43:39.0 +0100
---
Jaime Casanova wrote:
* If a table with the same name already exists when a partition
is created, the table is re-used as partition. This behavior
is required for pg_dump to be simple.
i guess the table must be empty, if not we should be throw an error...
and i actually prefer some
Pavel Stehule pavel.steh...@gmail.com wrote:
sorry, it's problem in my english
In hopes that it may help overcome the language barrier if someone
restates the issue in different words, I'll echo Tom's concerns, which
I share.
This cannot change an behave of older applications.
Agreed.
2009/11/17 Kevin Grittner kevin.gritt...@wicourts.gov:
Pavel Stehule pavel.steh...@gmail.com wrote:
sorry, it's problem in my english
In hopes that it may help overcome the language barrier if someone
restates the issue in different words, I'll echo Tom's concerns, which
I share.
This
On Tue, Nov 17, 2009 at 3:04 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello,
this small patch add missing USING clause to OPEN FOR EXECUTE statement
+ cleaning part of exec_stmt_open function
see http://archives.postgresql.org/pgsql-hackers/2009-11/msg00713.php
This is now the
2009/11/17 Robert Haas robertmh...@gmail.com:
On Tue, Nov 17, 2009 at 3:04 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello,
this small patch add missing USING clause to OPEN FOR EXECUTE statement
+ cleaning part of exec_stmt_open function
see
2009/11/17 Pavel Stehule pavel.steh...@gmail.com:
2009/11/17 Robert Haas robertmh...@gmail.com:
On Tue, Nov 17, 2009 at 3:04 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello,
this small patch add missing USING clause to OPEN FOR EXECUTE statement
+ cleaning part of exec_stmt_open
Pavel Stehule pavel.steh...@gmail.com wrote:
2009/11/17 Robert Haas robertmh...@gmail.com:
This is now the fourth patch you've submitted since the start of
the CommitFest...
These patches are for next commitfest. What I know, the current
commitfest is closed for new patches. Is it ok?
2009/11/17 Kevin Grittner kevin.gritt...@wicourts.gov:
Pavel Stehule pavel.steh...@gmail.com wrote:
2009/11/17 Robert Haas robertmh...@gmail.com:
This is now the fourth patch you've submitted since the start of
the CommitFest...
These patches are for next commitfest. What I know, the
On Tue, 2009-11-17 at 14:33 -0600, Kevin Grittner wrote:
Pavel Stehule pavel.steh...@gmail.com wrote:
2009/11/17 Robert Haas robertmh...@gmail.com:
This is now the fourth patch you've submitted since the start of
the CommitFest...
These patches are for next commitfest. What I
Perhaps the OP should explain exactly what real-world problems he's
trying to solve. As noted in the discussion you linked, there's not
a lot of enthusiasm around here for getting closer to the spec's
datetime handling simply because it's the spec; that part of the spec
is just too broken
2009/11/17 Joshua D. Drake j...@commandprompt.com:
On Tue, 2009-11-17 at 14:33 -0600, Kevin Grittner wrote:
Pavel Stehule pavel.steh...@gmail.com wrote:
2009/11/17 Robert Haas robertmh...@gmail.com:
This is now the fourth patch you've submitted since the start of
the CommitFest...
Pavel Stehule pavel.steh...@gmail.com wrote:
I never sent these (last two) patches to THIS commitfest. Is it
clean?
Counting the In Progress commitfest and the two preceding ones, you
have submitted nine patches and contributed to the review of none.
Surely you noticed recent threads about
Pavel submitted a patch to add typmods to function declarations, but there
was no prior design discussion and it desperately needs some. Let me try
to summarize the issues that seem to need agreement.
The proposed patch allows optional typmods to be attached to the declared
argument and result
On Tue, 2009-11-17 at 15:40 -0600, Kevin Grittner wrote:
Pavel Stehule pavel.steh...@gmail.com wrote:
I never sent these (last two) patches to THIS commitfest. Is it
clean?
I'm sure it would be much appreciated, and help to alleviate the
frustration and burnout of some other
On Nov 17, 2009, at 9:15 AM, Andrew Dunstan wrote:
Indeed. I once suggested only half jokingly that we should have a Coder of
the month award.
I suggest that it be named The Tom Lane award, and disqualify Tom from
winning (sorry Tom). ;-)
David
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
Pavel submitted a patch to add typmods to function declarations, but there
was no prior design discussion and it desperately needs some. Let me try
to summarize the issues that seem to need agreement.
[excellent summary of problem areas snipped]
Unless we have
hernan gonzalez hgonza...@gmail.com wrote:
I believe that this distinction between two realms: one related to
(say) physical time and the other to (say) civil date-time, is
the key to put some order... conceptually, at least (I'm not
speaking about feasibility for now). This is the approach
Pavel Stehule wrote:
I don't wont to apply these patches tomorrow, I don't sending these
patches for last moment. If I have to wait one weak or two weeks, ok.
Declare it. I'll respect it. But actually I respecting all rules, what
I know.
If you're sending stuff intended for the next
On Thu, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote:
I think syntax support is a good start.
I don't see a syntax-only patch as being any use at all to this
community.
We go to enormous lengths in other areas to never allow patches with
restrictions. Why would we allow a patch that is
2009/11/17 Joshua Tolley eggyk...@gmail.com:
On Sun, Nov 15, 2009 at 12:10:33PM +1100, Brendan Jurd wrote:
I noticed that there was a fairly large amount of bogus/inconsistent
whitespace
...
Thanks -- I tend to forget whitespace :)
In the documentation you refer to this feature as inline
On Wed, Nov 18, 2009 at 09:35:35AM +1100, Brendan Jurd wrote:
2009/11/17 Joshua Tolley eggyk...@gmail.com:
On Sun, Nov 15, 2009 at 12:10:33PM +1100, Brendan Jurd wrote:
I noticed that there was a fairly large amount of bogus/inconsistent
whitespace
...
Thanks -- I tend to forget
On Nov 9, 2009, at 6:07 PM, Joshua Tolley wrote:
Ok, updated patch attached. As far as I know, this completes all outstanding
issues:
1) weird comment in plperl.c is corrected and formatted decently
2) plperlu vs. plperl actually works (thanks again, Andrew)
3) docs included
4)
Le 17 nov. 2009 à 20:33, Tom Lane a écrit :
We could to talk about it now. We are not hurry. But I would to see
some progress in this area in next two months. This patch is simple
and doesn't create any new rules or doesn't change behave.
What do you mean it doesn't change the behavior? It
On Tue, Nov 17, 2009 at 5:34 PM, Greg Smith g...@2ndquadrant.com wrote:
Pavel Stehule wrote:
I don't wont to apply these patches tomorrow, I don't sending these
patches for last moment. If I have to wait one weak or two weeks, ok.
Declare it. I'll respect it. But actually I respecting all
Andrew Dunstan and...@dunslane.net writes:
Apart from all these it's not clear to me what the major benefits of
doing this would be. I'd like an explanation of that to start with.
Well, aside from the issue about making anyelement more powerful
(which could be done in other ways), I can think
Alexey Klyukin wrote:
I've noticed that the patch doesn't install current_call_data before calling
plperl_call_perl_func, although it saves and restores its previous value. This
breaks spi code, which relies on current_call_data-prodesc, i.e.:
postgres=# DO $$ $result =
Hello
This has been discussed in #postgresql and posted to -performance a
couple days ago, but no solution has been found. The discussion can be
found here:
http://archives.postgresql.org/pgsql-performance/2009-11/msg00162.php
I just finished implementing a search engine for my site and
Alex Hunsaker escreveu:
BTW anyone know how to escape and for google?
You can escape and using lt; and gt;, respectively.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Robert Haas wrote:
This expresses my feelings on the topic exactly, and perhaps merits
inclusion in a Wiki page someplace. Maybe we need to have a wiki page
on commitfest rules expectations.
I put a note at
http://wiki.postgresql.org/wiki/Submitting_a_Patch#Submission_timing
which seems
Hello
This has been discussed in #postgresql and posted to -performance a
couple days ago, but no solution has been found. The discussion can be
found here:
http://archives.postgresql.org/pgsql-performance/2009-11/msg00162.php
I just finished implementing a search engine for my site and
Wojciech Knapik escreveu:
PS. This issue is not related to the loading time of dictionaries, or
calls to ts_headline for results that won't be displayed.
So what? Could you post the profiling of that query?
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers
Euler Taveira de Oliveira wrote:
PS. This issue is not related to the loading time of dictionaries, or
calls to ts_headline for results that won't be displayed.
So what? Could you post the profiling of that query?
Polish:
http://pastie.textmate.org/private/8lhmnbvde43lfjoxc52r1q
English:
On Tue, Nov 17, 2009 at 6:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Apart from all these it's not clear to me what the major benefits of
doing this would be. I'd like an explanation of that to start with.
Well, aside from the issue about making
On Tue, Nov 17, 2009 at 6:39 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Alex Hunsaker escreveu:
BTW anyone know how to escape and for google?
You can escape and using lt; and gt;, respectively.
Searching for lt;foo looks for documents containing lt and foo,
not documents
Kevin Grittner kevin.gritt...@wicourts.gov writes:
hernan gonzalez hgonza...@gmail.com wrote:
I believe that this distinction between two realms: one related to
(say) physical time and the other to (say) civil date-time, is
the key to put some order... conceptually, at least (I'm not
speaking
Robert Haas robertmh...@gmail.com writes:
So I guess really can't get worked up about the idea of propagating
this information through the type system. Even suppose we eventually
take the steps you suggesting and make it so that varchar(30) ||
varchar(40) yields varchar(70). What good is
Robert Haas escreveu:
On Tue, Nov 17, 2009 at 6:39 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Alex Hunsaker escreveu:
BTW anyone know how to escape and for google?
You can escape and using lt; and gt;, respectively.
Searching for lt;foo looks for documents containing lt
On Tue, Nov 17, 2009 at 4:31 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote:
I think syntax support is a good start.
I don't see a syntax-only patch as being any use at all to this
community.
We go to enormous lengths in other areas
On Tue, Nov 17, 2009 at 7:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So I guess really can't get worked up about the idea of propagating
this information through the type system. Even suppose we eventually
take the steps you suggesting and make it so
Wojciech Knapik escreveu:
Euler Taveira de Oliveira wrote:
PS. This issue is not related to the loading time of dictionaries, or
calls to ts_headline for results that won't be displayed.
So what? Could you post the profiling of that query?
I was talking about gprof (--enable-profiling),
On Tue, Nov 17, 2009 at 06:05:19PM -0500, Andrew Dunstan wrote:
Alexey Klyukin wrote:
I've noticed that the patch doesn't install current_call_data before calling
plperl_call_perl_func, although it saves and restores its previous value.
This breaks spi code, which relies on
Hi,
I noticed that some example functions don't contain the magic block and that
leads to error while loading those examples in 8.2 or later.
Attached is a patch that adds it. I also add some missing header file. Don't
have a strong opinion about backpatching it or not.
--
Euler Taveira de
Joshua Tolley wrote:
+ plperl_call_data *save_call_data = current_call_data;
+ boololdcontext = trusted_context;
+
+ if (SPI_connect() != SPI_OK_CONNECT)
+ elog(ERROR, could not connect to SPI manager);
...
+ current_call_data =
there's something about the current version of the dictionary that
we don't like. I used sjp-ispell-pl-20091117-src.tar.bz2 ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
Peter Eisentraut pete...@gmx.net wrote:
Together, that should cover a lot of cases. Not perfect, but far from
useless.
For Japanese users on Windows, the client encoding are always set to SJIS
because of the restriction of cmd.exe. But the script file can be written
in UTF8 with BOM. I don't
Andrew Dunstan and...@dunslane.net wrote:
Itagaki Takahiro wrote:
Multi-byte scripts
without encoding are always dangerous whether BOM is present or not.
I'd say we can always throw an error when we find queries that contain
multi-byte characters if no prior encoding declaration.
On Sat, Nov 14, 2009 at 2:27 PM, Jeff Davis pg...@j-davis.com wrote:
New patches attached.
Forgive me if this is discussed before, but why does this store the
strategy numbers of the relevant operators instead of the operators
themselves? It seems like this could lead to surprising behavior if
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
Jaime Casanova wrote:
PARTITION name VALUES LESS THAN { range_upper | MAXVALUE }
| PARTITION name VALUES IN ( list_value [,...] | DEFAULT )
i remember someone making a comment about actually using operators
instead of LESS
hernan == hernan gonzalez hgonza...@gmail.com writes:
Perhaps the OP should explain exactly what real-world problems
he's trying to solve. As noted in the discussion you linked,
there's not a lot of enthusiasm around here for getting closer to
the spec's datetime handling simply because
Itagaki Takahiro wrote:
I don't want user to check the encoding of scripts before executing --
it is far from fail-safe.
That's what we require in all other cases. Why should UTF8 be special?
If I have a script in Latin1 and Postgres thinks it's UTF8 it will
probably explode. Same for
Simon Riggs si...@2ndquadrant.com wrote:
Why not just wait until we have a whole patch and then apply?
A whole patch can be written by many contributers instead of only
one person, no? I think we need to split works for partitioning
into serveral parts to encourage developing it. I just did
Andrew Dunstan and...@dunslane.net wrote:
Itagaki Takahiro wrote:
I don't want user to check the encoding of scripts before executing --
it is far from fail-safe.
That's what we require in all other cases. Why should UTF8 be special?
No. I didn't think about UTF-8 nor BOM in that
1 - 100 of 108 matches
Mail list logo
