Alright, I wrote up another patch that uses strchr to parse out the
lines of the unaccent.rules file, foregoing sscanf completely.
Hopefully this looks a bit better than using swscanf.
As for the other problems with isspace and such on OSX, it might be
worth looking at the python portability fixes
Hi,
when I insert/update many rows at once using INSERT ... SELECT into a
table which has plenty of CHECK constraints, the error message that
Postgres returns has no indication of which row failed the constraint
check. The attached patch tries to provide information in a similar way
to how duplicat
On 07/11/11 10:20, Bernd Helmle wrote:
--On 6. November 2011 01:08:11 -0200 Greg Smith
wrote:
Attached patch adds a new function to the pageinspect extension for
measuring
total free space, in either tables or indexes.
I wonder if that should be done in the pgstattuple module, which
ou
On 2011-11-06, at 7:15 PM, Tom Lane wrote:
>
> swscanf doesn't seem like an acceptable approach: it's a function that
> is relied on nowhere else in PG, so it adds new portability risks of its
> own. It doesn't exist on some platforms that we support (like the one
> I'm typing this message on) an
I'm looking for known problem areas in btree_gist. I see:
http://archives.postgresql.org/message-id/8973.1286841...@sss.pgh.pa.us
With Range Types, I'm anticipating that btree_gist will become more
important, so I'd like to know what bugs are holding it back.
So, anything else come to mind? Or d
J Smith writes:
> I've attached a patch against master for unaccent.c that uses swscanf
> along with char2wchar and wchar2char instead of sscanf directly to
> initialize the unaccent extension and it appears to fix the problem in
> both the master and 9.1 branches.
swscanf doesn't seem like an ac
On Sun, Nov 6, 2011 at 1:18 PM, Florian Pflug wrote:
>
> What's the locale of the database you're seeing this in, and which charset
> does it use?
>
> I think scanf() uses isspace() and friends, and last time I looked the
> locale definitions where all pretty bogus on OSX. So maybe scanf() somehow
Peter Geoghegan writes:
> On 6 November 2011 15:08, Tom Lane wrote:
>> Are you intending to hash the raw
>> grammar output tree, the parse analysis result, the rewriter result,
>> or the actual plan tree?
> I'm hashing the Query tree from a planner plugin (function assigned to
> planner_hook), i
On 6 November 2011 15:08, Tom Lane wrote:
> Are you intending to hash the raw
> grammar output tree, the parse analysis result, the rewriter result,
> or the actual plan tree?
I'm hashing the Query tree from a planner plugin (function assigned to
planner_hook), immediately prior to it being passe
--On 6. November 2011 01:08:11 -0200 Greg Smith wrote:
Attached patch adds a new function to the pageinspect extension for measuring
total free space, in either tables or indexes.
I wonder if that should be done in the pgstattuple module, which output some
similar numbers.
--
Thanks
On Sun, Nov 6, 2011 at 1:16 PM, Dickson S. Guedes wrote:
>> test=# \d+ foo
>> Table "public.foo"
>> Column | Type | Storage
>> +-+-
>> a | integer | plain
>> b | integer | plain
>> Has OIDs: no
>
> Using your example, what if column '
On Sun, Nov 6, 2011 at 04:08, Greg Smith wrote:
> Attached patch adds a new function to the pageinspect extension for
> measuring total free space, in either tables or indexes. It returns the
> free space as a percentage, so higher numbers mean more bloat. After trying
> a couple of ways to quan
On 11/06/2011 01:08 PM, Tom Lane wrote:
Peter Geoghegan writes:
... It also does things
like intelligently distinguishing between queries with different
limit/offset constant values, as these constants are deemed to be
differentiators of queries for our purposes. A guiding principal that
I'
On 2011-11-04 01:12, Alvaro Herrera wrote:
I would like some opinions on the ideas on this patch, and on the patch
itself. If someone wants more discussion on implementation details of
each part of the patch, I'm happy to provide a textual description --
please just ask.
Jumping in a bit late
On 2011-11-03 17:26, Marko Kreen wrote:
On Mon, Oct 31, 2011 at 7:09 PM, Tom Lane wrote:
Can't you do that today with a multi-command string submitted to
PQsendQuery, followed by multiple calls to PQgetResult?
It's more annoying to to error handling on that, plus it still keeps the
blocking b
On 6 Listopad 2011, 16:08, Tom Lane wrote:
> Peter Geoghegan writes:
>> I'm a couple of days away from posting a much better principled
>> implementation of pg_stat_statements normalisation. To normalise, we
>> perform a selective serialisation of the query tree, which is hashed.
>
> That seems li
On Nov6, 2011, at 18:43 , J Smith wrote:
> I put some elog debugging lines into unaccent.c and found that sscanf
> sometimes reads the scanned line by finding only one byte for the for
> the source character rather than the two required for the complete
> UTF-8 code point. It appears that the follo
2011/11/5 Josh Kupershmidt :
> I'd like to propose a "concise mode" for psql, which users might turn
> on via a \pset option. Concise mode would affect only the output of
> psql's backslash commands. For output results which have some all-NULL
> columns, as in:
>
> test=# \d+ foo
>
Tomas Vondra writes:
> If it was possible to compare the actual plan (or at least a hash of the
> plan), and keeping one record for each plan, that'd be extremely nice.
> You'd see that the query was executed with 3 different plans, number of
> calls, average duration etc.
I like that idea. How
Gah! Accidentally hit Send. Let me finish that last message before
sending this time!
G'day list.
I've been messing around with the unaccent extension and I've noticed
that some of the characters listed in the unaccent.rules file aren't
actually being unaccented on my system.
Here are the syste
G'day list.
I've been messing around with the unaccent extension and I've noticed
that some of the characters listed in the unaccent.rules file aren't
actually being unaccented on my system.
Here are the system details and whatnot.
- OSX 10.7.2
- the server is compiled via macports. Tried using
hubert depesz lubaczewski writes:
> checked lengths of the text/varchar columns in database.
> there are 16 such columns in the table.
> full report of lengths is in
> http://www.depesz.com/various/lengths.report.gz
> it was obtained using:
> select length( "first_text_column" ) as length_1, cou
On Fri, Nov 04, 2011 at 09:04:02PM -0400, Tom Lane wrote:
> that. And that they are the only rows that, in addition to the above
> conditions, contain data fields wide enough to require out-of-line
> toasting.
checked lengths of the text/varchar columns in database.
there are 16 such columns in
hubert depesz lubaczewski writes:
> Any chance of getting the fix in patch format so we could test it on
> this system?
http://git.postgresql.org/gitweb/?p=postgresql.git;a=patch;h=23998fe99c1220ba3a9eefee194e37ec1f14ae07
regards, tom lane
--
Sent via pgsql-hackers mail
Peter Geoghegan writes:
> I'm a couple of days away from posting a much better principled
> implementation of pg_stat_statements normalisation. To normalise, we
> perform a selective serialisation of the query tree, which is hashed.
That seems like an interesting approach, and definitely a lot le
On Fri, 2011-11-04 at 11:22 +0100, Pavel Stehule wrote:
> Hello
>
> I found a interesting issue when I checked a tsearch prefix searching.
>
> We use a ispell based dictionary
>
> CREATE TEXT SEARCH DICTIONARY cspell
>(template=ispell, dictfile = czech, afffile=czech, stopwords=czech);
> CRE
26 matches
Mail list logo
