>
> 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 t
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
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, b
Hi,
Pavel Stehule 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 the
need to have more tha
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
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 wo
George Gensure 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
> alluded to wi
Dimitri Fontaine 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?
TBD, really. It wa
"Greg Sabino Mullane" 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
> default value
Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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
1821child_rel
Emmanuel Cecchet 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 the memory i
2009/11/17 Tom Lane :
> Dimitri Fontaine 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 s
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 (p
Tom Lane wrote:
Emmanuel Cecchet 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, i
Robert Haas wrote:
> On Mon, Nov 16, 2009 at 11:07 AM, Kevin Grittner
> 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 to commit as long as any of the
>>
On Tue, Nov 17, 2009 at 10:21 AM, hernan gonzalez 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 ?
> http://wiki.postgresql.org/wiki/Todo#Dates_and_T
Peter Eisentraut 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. This entir
On Tue, Nov 17, 2009 at 03:54, Marko Tiikkaja
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 top level of with.
>
> T
Emmanuel Cecchet 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 for COPY? Repeat
Robert Haas 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
associated data ... but
Tom Lane wrote:
Emmanuel Cecchet 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 cach
On Mon, Nov 16, 2009 at 9:56 PM, Alvaro Herrera
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?
I've just write the
>
> 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 compar
On Mon, Nov 16, 2009 at 10:17 PM, Andres Freund 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 8.3)
>
Emmanuel Cecchet 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 cached?
> Why do I
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
expected/plpython_do.sql
Valtonen, Hannu wrote:
> I couldn't figure out how to get added files to show in git diff ...
git add
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 (pgsql-hacker
On tis, 2009-11-17 at 09:31 +0900, Itagaki Takahiro wrote:
> Peter Eisentraut 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 will be
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 Mc
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 impl
> -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
Pavel Stehule writes:
> 2009/11/17 Tom Lane :
>> 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
>> not lock ourselves into a half-bake
Andrew Dunstan 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 require a protocol
Tom Lane wrote:
Andrew Dunstan 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 imp
2009/11/17 Tom Lane :
> Pavel Stehule writes:
>> 2009/11/17 Tom Lane :
>>> 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
>>> not lo
Andrew Dunstan 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 writes:
> 2009/11/17 Tom Lane :
>> 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 about function identity or coercion
2009/11/17 Tom Lane :
> Pavel Stehule writes:
>> 2009/11/17 Tom Lane :
>>> 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 about fu
Sergey Konoplev escribió:
> On Mon, Nov 16, 2009 at 9:56 PM, Alvaro Herrera
> 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 p
Pavel Stehule writes:
> 2009/11/17 Tom Lane :
>> 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 could to talk about it now. We are no
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 I
On Thu, Nov 12, 2009 at 5:54 AM, Itagaki Takahiro
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 seen the patch but:
>
> *
2009/11/17 Tom Lane :
> Pavel Stehule writes:
>> 2009/11/17 Tom Lane :
>>> 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 could t
Tom Lane escribió:
> George Gensure 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 have
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
--- ./do
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 more
Pavel Stehule 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. That's not the problem.
2009/11/17 Kevin Grittner :
> Pavel Stehule 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 applicatio
On Tue, Nov 17, 2009 at 3:04 PM, Pavel Stehule 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 fourth patch you've s
2009/11/17 Robert Haas :
> On Tue, Nov 17, 2009 at 3:04 PM, Pavel Stehule
> 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
>
2009/11/17 Pavel Stehule :
> 2009/11/17 Robert Haas :
>> On Tue, Nov 17, 2009 at 3:04 PM, Pavel Stehule
>> 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.or
Pavel Stehule wrote:
> 2009/11/17 Robert Haas :
>> 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?
Until this moment I was unconvinced
2009/11/17 Kevin Grittner :
> Pavel Stehule wrote:
>> 2009/11/17 Robert Haas :
>
>>> 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?
>
On Tue, 2009-11-17 at 14:33 -0600, Kevin Grittner wrote:
> Pavel Stehule wrote:
> > 2009/11/17 Robert Haas :
>
> >> 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
> 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 broke
2009/11/17 Joshua D. Drake :
> On Tue, 2009-11-17 at 14:33 -0600, Kevin Grittner wrote:
>> Pavel Stehule wrote:
>> > 2009/11/17 Robert Haas :
>>
>> >> This is now the fourth patch you've submitted since the start of
>> >> the CommitFest...
>> >>
>> >
>> > These patches are for next commitfest. Wha
Pavel Stehule 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 how the review and c
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 ty
On Tue, 2009-11-17 at 15:40 -0600, Kevin Grittner wrote:
> Pavel Stehule 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 contributors, if you cou
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 consensus
hernan gonzalez 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 of some
> Da
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 CommitFest
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 es
2009/11/17 Joshua Tolley :
> 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 functions"
On Wed, Nov 18, 2009 at 09:35:35AM +1100, Brendan Jurd wrote:
> 2009/11/17 Joshua Tolley :
> > 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
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) r
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 behavio
On Tue, Nov 17, 2009 at 5:34 PM, Greg Smith 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 rules, what
>>
Andrew Dunstan 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 of:
If we don't
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 = spi_exec_query("sel
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 fo
Alex Hunsaker escreveu:
> BTW anyone know how to escape < and > for google?
>
You can escape < and > using < and >, 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 t
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 an
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-hacke
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:
h
On Tue, Nov 17, 2009 at 6:01 PM, Tom Lane wrote:
> Andrew Dunstan 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
On Tue, Nov 17, 2009 at 6:39 PM, Euler Taveira de Oliveira
wrote:
> Alex Hunsaker escreveu:
>> BTW anyone know how to escape < and > for google?
>>
> You can escape < and > using < and >, respectively.
Searching for
"Kevin Grittner" writes:
> hernan gonzalez 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).
>
Robert Haas 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 that? Why would anyo
Robert Haas escreveu:
> On Tue, Nov 17, 2009 at 6:39 PM, Euler Taveira de Oliveira
> wrote:
>> Alex Hunsaker escreveu:
>>> BTW anyone know how to escape < and > for google?
>>>
>> You can escape < and > using < and >, respectively.
>
> Searching for
On Tue, Nov 17, 2009 at 4:31 PM, Simon Riggs 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 to never allow
On Tue, Nov 17, 2009 at 7:46 PM, Tom Lane wrote:
> Robert Haas 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)
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 (--enabl
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 curr
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 O
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 = (plperl_call
ec (15a)
"
u8=#
Seems 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
Peter Eisentraut 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 think we shou
Andrew Dunstan 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.
>
> You will br
On Sat, Nov 14, 2009 at 2:27 PM, Jeff Davis 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
the user modifies
Marko Tiikkaja 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 THEN and family
>
> "hernan" == hernan gonzalez 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 it's
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 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 one of
the parts, "s
Andrew Dunstan 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 point.
I assumed w
1 - 100 of 108 matches
Mail list logo
