Hi,
On Thu, Apr 9, 2009 at 4:11 AM, Guillaume Smet wrote:
> Hi,
>
> Following the discussion here
> http://archives.postgresql.org/message-id/49d9e986.8010...@pse-consulting.de
> , I wrote a small patch which rotates the last XLog file on shutdown
> so that the archive command is also executed fo
On Thursday 09 April 2009 02:24:53 Tom Lane wrote:
> Peter Eisentraut writes:
> > What is the purpose of fmgrtab anyway?
>
> It's so we can find the addresses of "internal" functions to call them.
Ah yes of course. But then the table can just as well be built by something
based on rgrep PG_FUNC
"Hiroshi Saito" wrote:
> Um, I had a focus in help the problem which is not avoided.
> I am not sensitive to a problem being avoided depending on usage.
> However, I will wish to work spontaneously, when it is help much.
I'll research whether encoding of filesystem path is affected by
local
Sam Mason writes:
> On Wed, Apr 08, 2009 at 06:11:59PM -0400, Tom Lane wrote:
>> Anyway, I revised this a bit and applied to HEAD.
> I've not tested; but your changes look as though they will break:
> SELECT 'Infinity'::float::numeric;
That gives an error now, just as it did before, so I'm not
On Wed, Apr 08, 2009 at 06:11:59PM -0400, Tom Lane wrote:
> Sam Mason writes:
> > On Tue, Apr 07, 2009 at 12:51:21PM -0400, Tom Lane wrote:
> >> IIRC, the explicit support for leading/trailing spaces is something that
> >> we added in float8in long after numeric_in was written, and I think just
>
On Thursday 02 April 2009 21:38:06 Tom Lane wrote:
> Heikki Linnakangas writes:
> > Now, what about the idea of providing a shorthand LOCALE='foo',
> > mirroring --locale=foo initdb option? It seems like a good idea, because
> > you almost never want to set LC_COLLATE and LC_CTYPE differently. If
Tom,
Like what? I do not actually believe that anyone needs an
interactive geographical timezone selector based on
pg_timezone_names.
Actually, considering that PostgreSQL is the leading open source GIS
database, I expect that a *lot* of people want this. Or, at least,
enough data to ad
Peter Eisentraut writes:
> What is the purpose of fmgrtab anyway?
It's so we can find the addresses of "internal" functions to call them.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
On Tuesday 07 April 2009 03:36:43 Tom Lane wrote:
> You won't get far with doing it to pg_proc: internal functions *have to*
> have entries in there, else the fmgrtab infrastructure for them doesn't
> get created. (Yeah, I suppose there are other ways to drive that, but
> the fact remains that the
Peter Eisentraut writes:
> Here is my thinking, and considering that that would basically involve a
> forward-looking design decision right now, I would support dropping the
> cardinality() function from 8.4 (if people agree that this is in fact the
> design decision to make).
At this point I'
On Wednesday 08 April 2009 21:56:38 Tom Lane wrote:
> > For my part, I'd like to know what things other than arrays
> > in the standard applies to. I think the most
> > sensible course is to make cardinality(array[]) behave consistently with
> > cardinality(other_stuff) when we get around to impl
Bruce Momjian writes:
> How that debug_print_parse outputs as LOG instead of DEBUG in 8.4,
> should it be log_print_parse?
No, it's still a debugging tool.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
Bruce Momjian writes:
> Alvaro Herrera wrote:
>> Tom Lane escribi?:
>>> BTW, I hesitate to mention this and perhaps upset a fragile consensus,
>>> but should we remove the special-case code in \df that tries to hide I/O
>>> functions by excluding functions that take or return cstring? I think
>>>
Sam Mason writes:
> On Tue, Apr 07, 2009 at 12:51:21PM -0400, Tom Lane wrote:
>> IIRC, the explicit support for leading/trailing spaces is something that
>> we added in float8in long after numeric_in was written, and I think just
>> nobody thought about numeric at the time. But it's clearly incon
How that debug_print_parse outputs as LOG instead of DEBUG in 8.4,
should it be log_print_parse?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hac
On Friday 27 March 2009 20:59:23 Tom Lane wrote:
> Done, but I noticed while testing that it's not real consistent:
>
> regression=# select xmlelement(name foo, 'infinity'::timestamp);
> ERROR: timestamp out of range
> DETAIL: XML does not support infinite timestamp values.
> regression=# select
kverdecia writes:
> Some one knows where can I download a full example of a variable length
> user defined type?
There are several in the contrib modules.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
On Wed, Apr 8, 2009 at 3:49 PM, kverdecia wrote:
> Hi,
>
> Some one knows where can I download a full example of a variable length
> user defined type? I'm trying to define one but I have problems with de
> output function.
have you looked at contrib? for example hstore?
merlin
--
Sent via pgs
Hi,
Some one knows where can I download a full example of a variable length
user defined type? I'm trying to define one but I have problems with de
output function.
Thanks
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.pos
Hi,
Following the discussion here
http://archives.postgresql.org/message-id/49d9e986.8010...@pse-consulting.de
, I wrote a small patch which rotates the last XLog file on shutdown
so that the archive command is also executed for this file and we are
sure we have all the useful XLog files when we p
Tom,
There is no equivalent of multi-dimensional arrays in other kinds of
collections, so I'm not seeing that there is any good guide there.
What else *does* SQL:2008 consider a collection?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsq
Josh Berkus writes:
> Tom,
>> change cardinality() for multi-dim arrays?
>>
>> Drop; there's no consensus that this should be changed
> Andrew pinged me on this. While there's no consensus that it should be
> changed, there's no consensus it shouldn't, either. And once we release
> it, we've
On Wed, 8 Apr 2009, Tom Lane wrote:
If the kernel can't read-ahead a seqscan by itself, it's unlikely to
be smart enough to be helped by posix_fadvise ... or at least so I
would think.
There's some interesting comments on this subject (and about what fadvise
DONTNEED does) in the RRD research
On Wed, 8 Apr 2009, Heikki Linnakangas wrote:
Josh Berkus wrote:
The other thing I was going to ask you about is using posix_fadvise as an
alternative to O_DIRECT for the xlog. O_DIRECT is, AFAIK, linux-only,
whereas there are "direct write" fadvise flags which work on multiple OSes.
What f
Tom,
change cardinality() for multi-dim arrays?
Drop; there's no consensus that this should be changed
Andrew pinged me on this. While there's no consensus that it should be
changed, there's no consensus it shouldn't, either. And once we release
it, we've set the way it operates in
On Wed, Apr 8, 2009 at 6:42 PM, Heikki Linnakangas
wrote:
> Dave Page wrote:
>>
>> On Wednesday, April 8, 2009, Josh Berkus wrote:
>>>
>>> Presumably fadvise is useless on Windows. Anyone know?
>>
>> It is.
>
> cygwin supports POSIX_FADV_SEQUENTIAL (and POSIX_FADV_NORMAL to revert it),
> but not
Tom Lane wrote:
> Magnus Hagander writes:
>> Heikki Linnakangas wrote:
>>> cygwin supports POSIX_FADV_SEQUENTIAL (and POSIX_FADV_NORMAL to revert
>>> it), but not any of the other flags. It maps it to
>>> NtSetInformationFile() like this:
>
>> We set this in our open() wrapper in the code today.
Magnus Hagander writes:
> Heikki Linnakangas wrote:
>> cygwin supports POSIX_FADV_SEQUENTIAL (and POSIX_FADV_NORMAL to revert
>> it), but not any of the other flags. It maps it to
>> NtSetInformationFile() like this:
> We set this in our open() wrapper in the code today.
Really? Where? I didn'
Josh Berkus wrote:
The other thing I was going to ask you about is using posix_fadvise as
an alternative to O_DIRECT for the xlog. O_DIRECT is, AFAIK,
linux-only, whereas there are "direct write" fadvise flags which work on
multiple OSes.
What flags are those? I don't see any posix_fadvise f
Heikki,
It's important to distinguish what kind of fadvise we're talking about.
The bitmap scan code issues hints about individual pages, using
posix_fadvise(... POSIX_FADV_WILLNEED). For increasing the readahead of
a sequential scan, you'd want to use POSIX_FADV_SEQUENTIAL. I believe
the suppor
Heikki Linnakangas wrote:
> Dave Page wrote:
>> On Wednesday, April 8, 2009, Josh Berkus wrote:
>>> Presumably fadvise is useless on Windows. Anyone know?
>>
>> It is.
>
> cygwin supports POSIX_FADV_SEQUENTIAL (and POSIX_FADV_NORMAL to revert
> it), but not any of the other flags. It maps it to
Kevin Grittner wrote:
Heikki Linnakangas wrote:
xlog.c now also uses POSIX_FADV_WONTNEED to drop WAL pages from the
OS cache after writing them.
Even when archiving is on?
No, not in that case.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers
Dave Page wrote:
On Wednesday, April 8, 2009, Josh Berkus wrote:
Presumably fadvise is useless on Windows. Anyone know?
It is.
cygwin supports POSIX_FADV_SEQUENTIAL (and POSIX_FADV_NORMAL to revert
it), but not any of the other flags. It maps it to
NtSetInformationFile() like this:
Heikki Linnakangas wrote:
> xlog.c now also uses POSIX_FADV_WONTNEED to drop WAL pages from the
> OS cache after writing them.
Even when archiving is on?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
Josh Berkus wrote:
On 4/8/09 9:44 AM, Tom Lane wrote:
Josh Berkus writes:
What about seq scans?
If the kernel can't read-ahead a seqscan by itself, it's unlikely to
be smart enough to be helped by posix_fadvise ... or at least so I
would think. Do you have reason to think differently?
Wel
On Wednesday, April 8, 2009, Josh Berkus wrote:
> On 4/8/09 9:44 AM, Tom Lane wrote:
>
> Josh Berkus writes:
>
> What about seq scans?
>
>
> If the kernel can't read-ahead a seqscan by itself, it's unlikely to
> be smart enough to be helped by posix_fadvise ... or at least so I
> would think. Do
On 4/8/09 9:44 AM, Tom Lane wrote:
Josh Berkus writes:
What about seq scans?
If the kernel can't read-ahead a seqscan by itself, it's unlikely to
be smart enough to be helped by posix_fadvise ... or at least so I
would think. Do you have reason to think differently?
Well, Solaris 10 + UFS
and...@tao11.riddles.org.uk (Andrew Gierth) writes:
> The usual conversation goes something like this (generally following
> on from some discussion of how to do timezone conversions):
>
> Q: how do I get the list of available zone names?
>
> A: see pg_timezone_names
>
> Q: but there's 1650/1400
Josh Berkus writes:
> What about seq scans?
If the kernel can't read-ahead a seqscan by itself, it's unlikely to
be smart enough to be helped by posix_fadvise ... or at least so I
would think. Do you have reason to think differently?
regards, tom lane
--
Sent via pgsql
On 4/7/09 10:17 PM, Tom Lane wrote:
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.
What about seq scans?
--
Josh Berkus
PostgreSQL Expert
On Wed, Apr 8, 2009 at 11:59 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Apr 8, 2009 at 10:33 AM, Tom Lane wrote:
>>> The main point is that the planner will prefer a bitmap scan for any
>>> query that's estimated to return more than quite a small number of rows.
>
>> That makes sense,
On Wed, Apr 8, 2009 at 4:35 PM, Kevin Field wrote:
> On Apr 8, 11:26 am, dp...@pgadmin.org (Dave Page) wrote:
>> Did you add
>>
>> shared_preload_libraries = '$libdir/plugins/plugin_debugger.dll'
>>
>> to postgresql.conf and restart the server per the README?
>
> Oh my goodness. No. Thank you so
Hi Itagaki-san.
Um, I had a focus in help the problem which is not avoided.
I am not sensitive to a problem being avoided depending on usage.
However, I will wish to work spontaneously, when it is help much.
Regards,
Hiroshi Saito
- Original Message -
From: "Itagaki Takahiro"
Alvaro Herrera wrote:
> Tom Lane escribi?:
>
> > BTW, I hesitate to mention this and perhaps upset a fragile consensus,
> > but should we remove the special-case code in \df that tries to hide I/O
> > functions by excluding functions that take or return cstring? I think
> > that its value has lar
Robert Haas writes:
> On Wed, Apr 8, 2009 at 10:33 AM, Tom Lane wrote:
>> The main point is that the planner will prefer a bitmap scan for any
>> query that's estimated to return more than quite a small number of rows.
> That makes sense, but what about the nestloop-over-inner-indexscan case?
W
On Apr 8, 11:26 am, dp...@pgadmin.org (Dave Page) wrote:
> Did you add
>
> shared_preload_libraries = '$libdir/plugins/plugin_debugger.dll'
>
> to postgresql.conf and restart the server per the README?
Oh my goodness. No. Thank you so much. It works fine now. I'll
have to add that to my upgrad
On Wed, Apr 8, 2009 at 10:33 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Apr 8, 2009 at 1:17 AM, Tom Lane wrote:
>>> And please note that we think bitmap scans are the larger part of
>>> the win anyway. What's left undone there is some marginal mopup.
>
>> Can you elaborate on this? I
On Wed, Apr 8, 2009 at 11:35 AM, Greg Stark wrote:
> On Wed, Apr 8, 2009 at 4:11 PM, John Lister
> wrote:
>> Cheers for the pointers. Am i right in thinking that if i get an array of
>> arrays, the nested arrays are sent in wire format as well - it seems to be
>> from the docs.
>
> No, you can't
Tom Lane escribió:
> BTW, I hesitate to mention this and perhaps upset a fragile consensus,
> but should we remove the special-case code in \df that tries to hide I/O
> functions by excluding functions that take or return cstring? I think
> that its value has largely disappeared given the new ove
On Wed, Apr 8, 2009 at 4:11 PM, John Lister
wrote:
Cheers for the pointers. Am i right in thinking that if i get an array of
arrays, the nested arrays are sent in wire format as well - it seems to
be
from the docs.
No, you can't easily get an array of arrays in Postgres. You can get
multi
Greg Stark writes:
> On Wed, Apr 8, 2009 at 3:49 PM, Bruce Momjian wrote:
>> We already had a huge discussion over 'S' and I think we did as good as
>> we can. I think we risk overcomplicating the API by adding U, but we
>> can revisit this in 8.5 once we get more feedback from users.
> I think
On Wed, Apr 8, 2009 at 4:11 PM, John Lister
wrote:
> Cheers for the pointers. Am i right in thinking that if i get an array of
> arrays, the nested arrays are sent in wire format as well - it seems to be
> from the docs.
No, you can't easily get an array of arrays in Postgres. You can get
multi-d
"John Lister" writes:
> Cheers for the pointers. Am i right in thinking that if i get an array of
> arrays, the nested arrays are sent in wire format as well - it seems to be
> from the docs.
Postgres doesn't have arrays of arrays. There are multi-dimensional
arrays, which aren't conceptually
On Wed, Apr 8, 2009 at 3:47 PM, Kevin Field wrote:
> On Apr 8, 10:32 am, dp...@pgadmin.org (Dave Page) wrote:
>> On Wed, Apr 8, 2009 at 2:48 PM, Kevin Field
>> wrote:
>> >> I'll see if I can get an updated build pushed out sometime today.
>>
>> > I finally got around to trying this out using the
On Wed, Apr 8, 2009 at 3:49 PM, Bruce Momjian wrote:
> We already had a huge discussion over 'S' and I think we did as good as
> we can. I think we risk overcomplicating the API by adding U, but we
> can revisit this in 8.5 once we get more feedback from users.
I think we'll need to take stock b
Merlin Moncure wrote:
On Wed, Apr 8, 2009 at 10:48 AM, John Lister
wrote:
Following this up, is there any docs on the binary wire format for arrays?
Thanks
Does java wrap libpq?
No. The JDBC driver is a Type 4 pure java driver. It implements the wire
protocol.
That's is w
No unfortunately not, it is a JDBC type 4 java which is entirely written in
java. I've patched (as pointed out in another list) the base version to
handle binary data (still a couple of issues that seem unfinished) which has
given me clues, but the patch only supports simple types. I'm looking t
Cheers for the pointers. Am i right in thinking that if i get an array of
arrays, the nested arrays are sent in wire format as well - it seems to be
from the docs.
Secondly, comments are a bit scarse in the code, but am i also right in
thinking that an array indexing can start at an arbitrary
On Wed, Apr 8, 2009 at 10:48 AM, John Lister
wrote:
> Following this up, is there any docs on the binary wire format for arrays?
>
> Thanks
>
Does java wrap libpq? If so, your best bet is probably going to be to
go the libpqtypes route. If you want help doing that, you are more
than welcome to a
Andrew Chernow wrote:
John Lister wrote:
Following this up, is there any docs on the binary wire format for
arrays?
None that I know of.
Check out the backend source: (array_recv() and array_send() functions)
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/arrayfuncs.c?
On Apr 8, 10:32 am, dp...@pgadmin.org (Dave Page) wrote:
> On Wed, Apr 8, 2009 at 2:48 PM, Kevin Field wrote:
> >> I'll see if I can get an updated build pushed out sometime today.
>
> > I finally got around to trying this out using the March 24th build,
> > and it has the same issue...
>
> I just
John Lister wrote:
Following this up, is there any docs on the binary wire format for arrays?
None that I know of.
Check out the backend source: (array_recv() and array_send() functions)
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/arrayfuncs.c?rev=1.154
Or, look at
Martin Pihlak wrote:
> Tom Lane wrote:
> > Well, if they're all in your search_path then plain old \df will do
> > fine. If they're not in your search path then I think it gets pretty
> > questionable whether they're "user defined" in a real sense. It seems
> > more likely that you've got a pile
Following this up, is there any docs on the binary wire format for arrays?
Thanks
- Original Message -
From: John Lister
To: pgsql-hackers@postgresql.org
Sent: Tuesday, April 07, 2009 7:54 PM
Subject: [HACKERS] Array types
Hi, using v8.3.5 and a number of client libraries
Robert Haas writes:
> On Wed, Apr 8, 2009 at 1:17 AM, Tom Lane wrote:
>> And please note that we think bitmap scans are the larger part of
>> the win anyway. What's left undone there is some marginal mopup.
> Can you elaborate on this? I'm fuzzy on why index scans can't benefit
> from this as
On Wed, Apr 8, 2009 at 2:48 PM, Kevin Field wrote:
>> I'll see if I can get an updated build pushed out sometime today.
>
> I finally got around to trying this out using the March 24th build,
> and it has the same issue...
I just installed it here on a clean VM and I see the docs, the SQL
script
Hi.
- Original Message -
From: "Hiroshi Inoue"
Tom Lane wrote:
"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 thi
> I'll see if I can get an updated build pushed out sometime today.
I finally got around to trying this out using the March 24th build,
and it has the same issue...
Kev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
On Wed, Apr 8, 2009 at 1:17 AM, Tom Lane wrote:
> 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 bitm
Teodor Sigaev wrote:
May be call of pg_bind_textdomain_codeset(textdomain(NULL)); should be
wrapped by ENABLE_NLS?
Yep, fixed. Thanks.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Log Message:
---
Tell gettext which codeset to use by calling bind_textdomain_codeset(). We
already did that on Windows, but it's needed on other platforms too when
LC_CTYPE=C. With other locales, we enforce (or trust) that the codeset of
the locale matches the server encoding so we don't
On Tue, Apr 07, 2009 at 12:51:21PM -0400, Tom Lane wrote:
> Sam Mason writes:
> > SELECT 'NaN'::float8;
> > SELECT ' NaN'::float8;
> > SELECT 'NaN '::float8;
> > SELECT '+NaN'::float8;
> > SELECT '-NaN'::float8;
>
> Well, the +- part must be an artifact of your strtod() implementation;
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander writes:
Tom Lane wrote:
What makes more sense to me is to add a table to encnames.c that
provides the gettext name of every encoding that we support.
Do you mean a separate table there, or should we add a new column to one
of the existin
Tom Lane wrote:
> "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 ha
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
brilliant i'll give it a go... Now to sort out java :)
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 wi
Tom Lane wrote:
> Well, if they're all in your search_path then plain old \df will do
> fine. If they're not in your search path then I think it gets pretty
> questionable whether they're "user defined" in a real sense. It seems
> more likely that you've got a pile of modules loaded, and which of
77 matches
Mail list logo
