Alvaro Herrera wrote:
His question was: is it possible that we're handing a NULL pointer to a
%s on fprintf? The involved code looks like this:
fprintf(stderr,
"%s: %lu total in %ld blocks; %lu free (%ld chunks); %lu
used\n",
set-
Peter Eisentraut wrote:
In practice you get either the GNU or the Solaris version of gettext, and at
least the GNU version can cope with all the encoding names that the currently
Windows-only code path produces.
It doesn't. On my laptop running Debian testing:
hlinn...@heikkilaptop:~$ LC_ALL
On Tuesday 07 April 2009 11:21:25 Heikki Linnakangas wrote:
> Peter Eisentraut wrote:
> > In practice you get either the GNU or the Solaris version of gettext, and
> > at least the GNU version can cope with all the encoding names that the
> > currently Windows-only code path produces.
>
> It doesn'
Hiroshi Inoue wrote:
Heikki Linnakangas wrote:
I just tried that, and it seems that gettext() does transliteration,
so any characters that have no counterpart in the database encoding
will be replaced with something similar, or question marks. Assuming
that's universal across platforms, and I
Heikki Linnakangas wrote:
Hiroshi Inoue wrote:
Heikki Linnakangas wrote:
I just tried that, and it seems that gettext() does transliteration,
so any characters that have no counterpart in the database encoding
will be replaced with something similar, or question marks. Assuming
that's univers
Tom Lane writes:
> As near as I can tell, every place where you see an explicit cast
> between char * and xmlChar * is probably broken. I think we ought
> to approach this by refactoring to have all those conversions go
> through subroutines, instead of blithely casting.
There is another issue
Hiroshi Inoue wrote:
What is wrong with checking if the codeset is valid using iconv_open()?
That would probably work as well. We'd have to decide what we'd try to
convert from with iconv_open(). Utf-8 might be a safe choice. We don't
currently use iconv_open() anywhere in the backend, though
Peter Eisentraut wrote:
On Tuesday 07 April 2009 11:21:25 Heikki Linnakangas wrote:
Using the name for the latin1 encoding in the currently Windows-only
mapping table, "LATIN1", you get no translation because that name is not
recognized by the system. Using the other name "ISO-8859-1", it works.
Tom Lane wrote:
> Magnus Hagander writes:
>> Tom Lane wrote:
>>> In view of the way that canonicalize_path() works, I can't help thinking
>>> this is going in precisely the wrong direction.
>
>> In a way, yes. But canonicalize_path() runs only in the backend, and
>> this is only in the frontend.
Magnus Hagander wrote:
>> The major stumbling block to doing either thing is not wishing to import
>> path.c into libpq. I think that the objection was partially code size
>> and partially namespace pollution (path.c doesn't use pg_ or similar
>> prefixes on its exported names). The latter is no
Are there any TODOs here?
---
Robert Haas wrote:
> On Fri, Apr 3, 2009 at 5:10 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Fri, Apr 3, 2009 at 4:29 PM, Tom Lane wrote:
> >>> Correct, but you've got the details all
Heikki Linnakangas writes:
> Hiroshi Inoue wrote:
>> What is wrong with checking if the codeset is valid using iconv_open()?
> That would probably work as well. We'd have to decide what we'd try to
> convert from with iconv_open().
The problem I have with that is that you are now guessing at *t
Magnus Hagander wrote:
> Magnus Hagander wrote:
>>> The major stumbling block to doing either thing is not wishing to import
>>> path.c into libpq. I think that the objection was partially code size
>>> and partially namespace pollution (path.c doesn't use pg_ or similar
>>> prefixes on its export
Magnus Hagander writes:
> Tom Lane wrote:
>> The major stumbling block to doing either thing is not wishing to import
>> path.c into libpq. I think that the objection was partially code size
>> and partially namespace pollution (path.c doesn't use pg_ or similar
>> prefixes on its exported names)
On Tue, Apr 7, 2009 at 9:55 AM, Bruce Momjian wrote:
> Are there any TODOs here?
I'd say that all of the items listed in my original email could be
TODOs. I'm planning to work on as many of them as I have time for.
Ramon Lawrence is also working on some related ideas, as discussed
upthread. AFA
I wrote:
> Since I'm the one who's hot about this, I'm willing to do the work.
Belay that ... I'll review your patch instead, later today sometime.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
Nikhil Sontakke wrote:
> Hi,
>
>
> > We've discussed before the idea that NOT NULL constraints should be
> > explicitly represented in pg_constraint, just like general CHECK
> > constraints (this would allow them to be named, have sane inheritance
> > behavior, etc). If we had that, then pg_attr
Bruce Momjian writes:
> Nikhil Sontakke wrote:
>> Warrants an entry in the TODO items list:
>>
>> * make NOT NULL constraints have pg_constraint entries, just like CHECK
>> constraints
> This is now a TODO item (I just updated the description):
> Store the constraint names of NOT NULL con
Did I miss the exciting conclusion or did this drift silently off radar?
I seem to recall three options:
1. Leave as is. Arguments: least effort, no backward compatibility
issues, since array_to_string evaluate both an array with single empty
string and an array with no elements to an empty st
Steve Crawford wrote:
Did I miss the exciting conclusion or did this drift silently off radar?
it was pretty well split between the options. tabled for another time.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgr
On Apr 7, 2009, at 8:07 AM, Steve Crawford wrote:
In scenario 2, there were two options:
2a. Return zero-element array.
2b. Return array with single empty-string element.
My impression was that among the "change" options, 2b had the most
support (it is the most useful for the use-cases I've e
Hi,
I've just noticed that the NUMERIC input function special cases NaN
values differently to the floating point input functions. For example
the following are all accepted (on my system anyway):
SELECT 'NaN'::float8;
SELECT ' NaN'::float8;
SELECT 'NaN '::float8;
SELECT '+NaN'::float8;
Hi Tom-san.
I want to solve one problem before the release of 8.4.
However, since it also seems to be the new feature,
if not enough for 8.4, you may suggest that it is 8.5.
In Japan, the local file name of a server is dealt with by SJIS.
The example present Postgres...
server_encoding = UTF-8
Sam Mason writes:
> I've just noticed that the NUMERIC input function special cases NaN
> values differently to the floating point input functions. For example
> the following are all accepted (on my system anyway):
> SELECT 'NaN'::float8;
> SELECT ' NaN'::float8;
> SELECT 'NaN '::float8;
"Hiroshi Saito" writes:
> I want to solve one problem before the release of 8.4.
> However, since it also seems to be the new feature,
> if not enough for 8.4, you may suggest that it is 8.5.
I'm not too clear on what this is really supposed to accomplish, but
we are hardly going to put code like
This is something the client code would request (or not). It would not
be sensible to try to force it from the server side, since if the client
doesn't request it it's likely that the client wouldn't understand the
data format.
Cheers for the quick reply, any chance of a pointer to the protocol
Does libpqtypes pass the array "over the wire" as an array? Ideally i'd like
to do this with jdbc, but might give me a pointer...
Thanks
- Original Message -
From: "Andrew Chernow"
To: "John Lister"
Cc:
Sent: Tuesday, April 07, 2009 8:15 PM
Subject: Re: [HACKERS] Array types
John
Dave Page wrote:
> The MSVC++ build system is a little lacking in it's ability to build
> against different versions of Perl and TCL. The attached patch doesn't
> fix that (unfortunately), but does update the hard-coded library names
> so we can use Perl 5.10 and TCL 8.5 with PG 8.4.
Applied, than
On Tue, Apr 7, 2009 at 3:35 PM, John Lister
wrote:
> Does libpqtypes pass the array "over the wire" as an array? Ideally i'd like
> to do this with jdbc, but might give me a pointer...
We send/receive the server's array format. This is not quite a C
array, and is definitely not a java array. It
Hi, I think I solved the problem in the parser and the planner, but I'm
stuck in the executor, I think is in the ExecSort function on nodeSort
around this code:
/*
* Scan the subplan and feed all the tuples to tuplesort.
*/
for (;;)
{
slot = E
Peter Eisentraut wrote:
On Tuesday 07 April 2009 13:09:42 Heikki Linnakangas wrote:
Patch attached. Instead of checking for LC_CTYPE == C, I'm checking
"pg_get_encoding_from_locale(NULL) == encoding" which is more close to
what we actually want. The downside is that
pg_get_encoding_from_locale(N
John Lister wrote:
Cheers, nice to know it is possible... Now to see if i can get
java/python to do the same :) or to use a modified libpq somehow...
If performance is your concern, you would probably get the best results
using the languages C glue interfrace. For instance, in java I think
Hi, using v8.3.5 and a number of client libraries (java, python, pgadmin) and
playing about with arrays.
They all return arrays as text, is it possible to configure postgresql to
return an array in native form (does postgresql support such a thing)? This is
using both the simple and extended qu
On Tue, Apr 7, 2009 at 3:11 PM, Tom Lane wrote:
> "John Lister" writes:
>> Hi, using v8.3.5 and a number of client libraries (java, python, pgadmin)
>> and playing about with arrays.
>> They all return arrays as text, is it possible to configure postgresql
>> to return an array in native form (d
"John Lister" writes:
> Hi, using v8.3.5 and a number of client libraries (java, python, pgadmin) and
> playing about with arrays.
> They all return arrays as text, is it possible to configure postgresql
> to return an array in native form (does postgresql support such a
> thing)?
This is someth
Tom Lane wrote:
> Greg Stark writes:
> > On Sun, Apr 5, 2009 at 6:54 PM, Robert Haas wrote:
> >> I'm excited about some of them, but not to the point of not wanting to
> >> ship beta. ?So +1 for removing them as per your suggestions.
>
> > I'm somewhat excited about posix_fadvise but my general
"Kevin Grittner" wrote:
> It appears that I need to put together a custom parser for
> tsearch2.
Reality check: I need to find start and end locations for all matches
of a regular expression in a text object, very similar to what is done
by setup_regexp_matches in regexp.c for the regexp_split_
Cheers, nice to know it is possible... Now to see if i can get
java/python to do the same :) or to use a modified libpq somehow...
Merlin Moncure wrote:
On Tue, Apr 7, 2009 at 3:35 PM, John Lister
wrote:
Does libpqtypes pass the array "over the wire" as an array? Ideally i'd like
to do th
İ have two question,
Backup and restore with C# (windos form) interface, or postgre scripts?
--
Regards, Feridun Türk
Robert Haas wrote:
> On Tue, Apr 7, 2009 at 9:55 AM, Bruce Momjian wrote:
> > Are there any TODOs here?
>
> I'd say that all of the items listed in my original email could be
> TODOs. I'm planning to work on as many of them as I have time for.
> Ramon Lawrence is also working on some related ide
Tom Lane wrote:
> Bruce Momjian writes:
> > Nikhil Sontakke wrote:
> >> Warrants an entry in the TODO items list:
> >>
> >> * make NOT NULL constraints have pg_constraint entries, just like CHECK
> >> constraints
>
> > This is now a TODO item (I just updated the description):
>
> > Store th
On Tuesday 07 April 2009 13:09:42 Heikki Linnakangas wrote:
> Patch attached. Instead of checking for LC_CTYPE == C, I'm checking
> "pg_get_encoding_from_locale(NULL) == encoding" which is more close to
> what we actually want. The downside is that
> pg_get_encoding_from_locale(NULL) isn't exactly
Magnus Hagander writes:
>> Answering myself here: the filesize for the "frontend only" part is
>> about 2k on this system.
> Long meeting, time for coding.. :-) Here's a rough patch. Is this about
> what you had in mind?
Hm, this seems to make the namespace pollution problem worse not better,
be
On Tue, Apr 7, 2009 at 5:11 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Tue, Apr 7, 2009 at 9:55 AM, Bruce Momjian wrote:
>> > Are there any TODOs here?
>>
>> I'd say that all of the items listed in my original email could be
>> TODOs. I'm planning to work on as many of them as I have ti
Robert Haas wrote:
> On Tue, Apr 7, 2009 at 5:11 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Tue, Apr 7, 2009 at 9:55 AM, Bruce Momjian wrote:
> >> > Are there any TODOs here?
> >>
> >> I'd say that all of the items listed in my original email could be
> >> TODOs. ?I'm planning to wor
On Fri, Apr 3, 2009 at 5:42 AM, Fujii Masao wrote:
> Here is the patch;
> - Smart failover is chosen if the trigger file labeled "smart" or
> an empty one exists.
> - Fast failover is chosen if the trigger file labeled "fast" exists,
> the signal (SIGUSR1 or SIGINT) is received or the wait timeo
On Mon, Apr 06, 2009 at 08:48:55PM -0400, Tom Lane wrote:
> Andrew Gierth writes:
> > At the VERY LEAST, can we PLEASE have the zone.tab file INSTALLED
> > WHERE IT BELONGS rather than simply ignored, so that even if
> > further requests to include the information in a system view go
> > unheard b
John Lister wrote:
They all return arrays as text, is it possible to configure postgresql
to return an array in native form (does postgresql support such a
thing)? This is using both the simple and extended query forms - i
couldn't see a way to say what return type i wanted in the protocol docs
David Fetter wrote:
> On Mon, Apr 06, 2009 at 08:48:55PM -0400, Tom Lane wrote:
> > Andrew Gierth writes:
> > > At the VERY LEAST, can we PLEASE have the zone.tab file INSTALLED
> > > WHERE IT BELONGS rather than simply ignored, so that even if
> > > further requests to include the information in
Any idea why I am seeing this warning with the new pg_start_backup()
'fast' flag?
xlog.c:6917: warning: variable `fast' might be clobbered by
`longjmp' or `vfork'
The line is in a PG_ENSURE_ERROR_CLEANUP() block. This is with gcc
version 2.95.3.
--
Bruce Momjian http
David Fetter writes:
> On Mon, Apr 06, 2009 at 08:48:55PM -0400, Tom Lane wrote:
>> I still see no point in this unless we expose the information in
>> pg_timezone_names, which requires rather more than a one-line patch.
> There's really no point, and a lot of good stuff lost,
Like what? I do n
On Apr 7, 2009, at 3:26 PM, Alvaro Herrera wrote:
Agreed, it seems to me that a patch to install zone.tab during "make
install" could be applied at this time (before beta so that packagers
don't complain that we didn't give them time to fix their file lists).
A more complete patch can be discuss
Bruce Momjian writes:
> Any idea why I am seeing this warning with the new pg_start_backup()
> 'fast' flag?
> xlog.c:6917: warning: variable `fast' might be clobbered by
> `longjmp' or `vfork'
> The line is in a PG_ENSURE_ERROR_CLEANUP() block. This is with gcc
> version 2.95.3.
Th
On Apr 7, 2009, at 12:54 PM, John Lister wrote:
Cheers, nice to know it is possible... Now to see if i can get java/
python to do the same :) or to use a modified libpq somehow...
http://python.projects.postgresql.org will do it for Python. =D
tho, only supports Python 3, which is still quite
Tom Lane wrote:
> Bruce Momjian writes:
> > Any idea why I am seeing this warning with the new pg_start_backup()
> > 'fast' flag?
>
> > xlog.c:6917: warning: variable `fast' might be clobbered by
> > `longjmp' or `vfork'
>
> > The line is in a PG_ENSURE_ERROR_CLEANUP() block. This is wi
Bruce Momjian writes:
> Tom Lane wrote:
>> We could stick a volatile on it but I'd like to find out why this
>> particular variable seems to need that.
> You ready for this; changing 'bool' to 'int' supressed the warning:
> int fast = PG_GETARG_BOOL(1);
Well, that's a compiler bug :-(
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> We could stick a volatile on it but I'd like to find out why this
> >> particular variable seems to need that.
>
> > You ready for this; changing 'bool' to 'int' supressed the warning:
> > int fast = PG_GETARG_BOOL(1);
>
>
David E. Wheeler wrote:
> On Apr 7, 2009, at 3:26 PM, Alvaro Herrera wrote:
>
>> Agreed, it seems to me that a patch to install zone.tab during "make
>> install" could be applied at this time (before beta so that packagers
>> don't complain that we didn't give them time to fix their file lists).
>>
> "Alvaro" == Alvaro Herrera writes:
>> Andrew did, in fact, submit the patch to install zone.tab.
Alvaro> Hmm, yeah, that he did. (Seems to be missing "make
Alvaro> uninstall" support though.)
The rm -rf in the uninstall rule seems to be sufficient for that.
(What _is_ missing, as I s
> "Tom" == Tom Lane writes:
> David Fetter writes:
>> On Mon, Apr 06, 2009 at 08:48:55PM -0400, Tom Lane wrote:
>>> I still see no point in this unless we expose the information in
>>> pg_timezone_names, which requires rather more than a one-line patch.
>> There's really no point, and
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Hiroshi Inoue wrote:
>>> What is wrong with checking if the codeset is valid using iconv_open()?
>
>> That would probably work as well. We'd have to decide what we'd try to
>> convert from with iconv_open().
>
> The problem I have with that is tha
On 2009-04-03, Simon Riggs wrote:
>
> On Fri, 2009-04-03 at 18:03 +0100, Greg Stark wrote:
>
>> I wonder if we need a whole class of index algorithms to deal
>> specifically with read-only tables
>
> I think we can drop the word "index" from the sentence as well.
>
> "Read-only" isn't an isolated
While answering a question about something else, I spotted another
omission regarding \ef - no tab-completion for it.
This is the trivial patch, not sure if there's any benefit in trying
to be more specific.
--
Andrew (irc:RhodiumToad)
Index: src/bin/psql/tab-complete.c
> "Andrew" == Andrew Gierth writes:
Andrew> While answering a question about something else, I spotted
Andrew> another omission regarding \ef - no tab-completion for it.
Andrew> This is the trivial patch, not sure if there's any benefit in
Andrew> trying to be more specific.
I missed a
Hi
> I assume you mean $subject and not what you wrote here.
Yes. Sorry it's my mistake.
>> I examined contrib/lo which offers this functionality.
>
> Yes. I wonder why the TODO item is there at all, when contrib/lo
> already solves it in a perfectly reasonable way.
As a user of database, I th
Hi,
"Hiroshi Saito" wrote:
> At this time, a copy file name is UTF-8. It was troubled by handling.:-(
> Then, I make this proposal patch.
I think the problem is not only in Windows but also in all platforms
where the database encoding doesn't match their OS's encoding.
Instead of Windows spe
On Mon, Apr 06, 2009 at 10:51:22PM -0700, David Fetter wrote:
> On Sun, Apr 05, 2009 at 05:57:46PM -0700, David Fetter wrote:
> > On Sun, Apr 05, 2009 at 08:55:07PM -0400, Tom Lane wrote:
> > > David Fetter writes:
> > > > On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:
> > > >> The \df
Tom,
finishing posix_fadvise patch
Push to TODO
So has fadvise been completely dropped from 8.4, or only partially?
change psql's \df output for window functions?
Drop; there's no consensus that this should be changed
Also, Fetter is currently working on a \dw for 8.5.
On Tue, Apr 7, 2009 at 5:57 PM, Bruce Momjian wrote:
>> I think perhaps Optimizer / Executor would be more appropriate, since
>> these are not about hash indices but rather about hash joins. I will
>> look at doing that.
>
> Yes, please.
Done. See what you think...
>> Also I think the last ite
On Tue, Apr 7, 2009 at 10:42 PM, Josh Berkus wrote:
> Tom,
>
>> finishing posix_fadvise patch
>>
>> Push to TODO
>
> So has fadvise been completely dropped from 8.4, or only partially?
Bitmap scans will support it, but index scans will not.
...Robert
--
Sent via pgsql-hackers mailing li
On Tue, Apr 7, 2009 at 6:42 PM, James Pye wrote:
> On Apr 7, 2009, at 12:54 PM, John Lister wrote:
>
>> Cheers, nice to know it is possible... Now to see if i can get java/python
>> to do the same :) or to use a modified libpq somehow...
>
> http://python.projects.postgresql.org will do it for Pyt
Andrew Gierth wrote:
> > "Andrew" == Andrew Gierth writes:
>
> Andrew> While answering a question about something else, I spotted
> Andrew> another omission regarding \ef - no tab-completion for it.
>
> Andrew> This is the trivial patch, not sure if there's any benefit in
> Andrew> tryin
higepon wrote:
> As a user of database, I think contrib/lo is not the best way.
> Because it's not a part of core PostgreSQL, users may forget to use them.
> Or it is a little messy to use.
> So I think we need to implement *Auto* delete functionality in PostgreSQL
> core.
(It would be a rare
Robert Haas writes:
> On Tue, Apr 7, 2009 at 10:42 PM, Josh Berkus wrote:
>> So has fadvise been completely dropped from 8.4, or only partially?
> Bitmap scans will support it, but index scans will not.
And please note that we think bitmap scans are the larger part of
the win anyway. What's le
On Tue, Apr 07, 2009 at 07:42:51PM -0700, Josh Berkus wrote:
> Tom,
>
>> finishing posix_fadvise patch
>>
>> Push to TODO
>
> So has fadvise been completely dropped from 8.4, or only partially?
>
>
>> change psql's \df output for window functions?
>>
>> Drop; there's no consensus that thi
Hi.
> wrote:
> (It would be a rare case, but) A large object might be referenced
> by two or more rows because LO interface is split into two steps;
> allocating oid and storing data for it. The oid could be stored in
> two or more places and auto deletion would break such usecases.
Indeed. We h
76 matches
Mail list logo
