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
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
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
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
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
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
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 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
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 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
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
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
> "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
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
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
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
> "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
> "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
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).
>>
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);
>
>
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:
> > 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
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
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 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
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
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 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
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
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
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
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 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
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 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
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
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
İ have two question,
Backup and restore with C# (windos form) interface, or postgre scripts?
--
Regards, Feridun Türk
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
"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_
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
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, 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
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
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
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
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
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
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
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
"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
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;
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
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;
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
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
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
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
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
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
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
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)
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
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
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
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
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.
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
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
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.
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
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'
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
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
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-
76 matches
Mail list logo
