On Wed, Oct 24, 2012 at 5:40 PM, Merlin Moncure wrote:
> On Wed, Oct 24, 2012 at 3:51 PM, Merlin Moncure wrote:
>> On Wed, Oct 24, 2012 at 3:33 PM, Tom Lane wrote:
>>> Merlin Moncure writes:
>>>> Yeah -- I have a case where a large number of joins are hap
On Wed, Oct 24, 2012 at 3:51 PM, Merlin Moncure wrote:
> On Wed, Oct 24, 2012 at 3:33 PM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> Yeah -- I have a case where a large number of joins are happening that
>>> have a lot of filtering based on expressions and thing
On Wed, Oct 24, 2012 at 3:33 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> Yeah -- I have a case where a large number of joins are happening that
>> have a lot of filtering based on expressions and things like that.
>
> Might be worth your while to install some indexes
On Wed, Oct 24, 2012 at 2:26 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> The following query runs fine: it estimates the returned rows pretty wel:
>> postgres=# explain analyze select * from foo where i > 100 and i < 1;
>
>> ...but if you introduce a float
On Wed, Oct 24, 2012 at 10:06 AM, Merlin Moncure wrote:
> I was chasing down a query that ran fine in 8.1 but had an near
> infinite runtime in 9.2. It turned out to be from a bad filter
> estimate that is surprisingly simple to reproduce:
Testing some more it turns out that this isn&#
I was chasing down a query that ran fine in 8.1 but had an near
infinite runtime in 9.2. It turned out to be from a bad filter
estimate that is surprisingly simple to reproduce:
postgres=# create table foo(i int);
CREATE TABLE
postgres=# insert into foo select 1000 + (v/200) from generate_series(
On Wed, Oct 24, 2012 at 2:21 AM, Craig Ringer wrote:
> On 10/24/2012 07:32 AM, gha...@gmail.com wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 7620
>> Logged by: Greg Hazel
>> Email address: gha...@gmail.com
>> PostgreSQL version: 9.2.1
>> Opera
On Tue, Oct 23, 2012 at 8:05 PM, Greg Hazel wrote:
> On Oct 23, 2012, at 6:03 PM, Merlin Moncure wrote:
>
>> On Tue, Oct 23, 2012 at 6:32 PM, wrote:
>>> The following bug has been logged on the website:
>>>
>>> Bug reference: 7620
>>>
On Tue, Oct 23, 2012 at 6:32 PM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7620
> Logged by: Greg Hazel
> Email address: gha...@gmail.com
> PostgreSQL version: 9.2.1
> Operating system: Amazon Linux
> Description:
>
> array_to_json(ARRAY['f
On Wed, Aug 29, 2012 at 10:44 AM, Chris Travers wrote:
>> I think there's a lot of circumstantial
>> support for that argument; consider the case of plpgsql declared
>> record variables for example...what happens to them?
>
>
> Again, the question is simply this:
>
> Are the table constraints for
Pavelic wrote:
>> >> On 13.3.2012. 20:49, Merlin Moncure wrote:
>> >>> I personally think it's an oversight. This was just discussed a
>> >>> couple of days ago here:
>> >>>
>> >>> http://postgresql.1045698.n5.nabble.com/Alte
On Mon, Aug 27, 2012 at 9:40 PM, Bruce Momjian wrote:
> On Wed, Mar 14, 2012 at 07:19:14PM +0100, Rikard Pavelic wrote:
>> On 13.3.2012. 20:49, Merlin Moncure wrote:
>> > I personally think it's an oversight. This was just discussed a
>> > couple of days ago here
On Tue, Jun 26, 2012 at 12:09 PM, Merlin Moncure wrote:
> On Tue, Jun 26, 2012 at 12:02 PM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> I suspect (but haven't had time to prove and may not for several days
>>> -- unfortunately going on vacation momentarily) tha
On Tue, Jun 26, 2012 at 12:02 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> I suspect (but haven't had time to prove and may not for several days
>> -- unfortunately going on vacation momentarily) that this might be
>> caused by pl/sh.
>
> Hm. The reported
On Tue, Jun 26, 2012 at 9:19 AM, Merlin Moncure wrote:
>> Ok, I'll look into reproducing the crash conditions. Unfortunately
>> this is a critical server and it crashed during a time sensitive
>> process. I can schedule a maintenance window though but it will have
>&
On Mon, Jun 25, 2012 at 10:03 AM, Merlin Moncure wrote:
> On Mon, Jun 25, 2012 at 9:57 AM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> 2012-06-25 09:08:08 CDT [postgres@ysanalysis_hes]: LOG: could not
>>> send data to client: Broken pipe
>>> 2012-06-25 0
On Mon, Jun 25, 2012 at 9:57 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> 2012-06-25 09:08:08 CDT [postgres@ysanalysis_hes]: LOG: could not
>> send data to client: Broken pipe
>> 2012-06-25 09:08:10 CDT [postgres@ysanalysis_hes]: LOG: unexpected
>> EOF on client
I got a crash on a production server this morning following during
very heavy load. This is postgres 9.1.3 on Linux (going to 9.1.4
asap). I didn't catch a core dump it doesn't look like one would help
anyways. Server is virtualized quad on vmware. Here is the log I
have:
2012-06-25 09:07:45
On Tue, May 22, 2012 at 4:08 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> Basically, $subject says it all. It's pretty easy to reproduce:
>> delete all the records from a large table and execute any sequentially
>> scanning query before autocvacuum comes around
Basically, $subject says it all. It's pretty easy to reproduce:
delete all the records from a large table and execute any sequentially
scanning query before autocvacuum comes around and cleans the table
up; the query will be uncancellable. This can result in fairly
pathological behavior in i/o co
On Tue, Mar 20, 2012 at 12:16 PM, Robert Haas wrote:
> I think Tom's correct about what the right behavior would be if
> composite types supported defaults, but they don't, never have, and
> maybe never will. I had a previous argument about this with Tom, and
> lost, though I am not sure that any
On Sat, Feb 25, 2012 at 7:23 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6489
> Logged by: Rikard Pavelic
> Email address: rikard.pave...@zg.htnet.hr
> PostgreSQL version: 9.1.2
> Operating system: Windows 7
> Description:
>
> I'm trying
On Wed, Mar 7, 2012 at 2:49 PM, Merlin Moncure wrote:
> On a practical level, the error blocks nothing -- you can bypass it
> trivially. It's just an annoyance that prevents things that users
> would like to be able to do with table row types. So I'd argue to
> remove the
On Wed, Mar 7, 2012 at 2:31 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Wed, Mar 7, 2012 at 11:45 AM, Mike Blackwell
>> wrote:
>>> alter table a add column even_more_stuff boolean not null default false;
>
>> aha! that's not what you posted last ti
On Wed, Mar 7, 2012 at 1:17 PM, Mike Blackwell wrote:
> As a followup, the workaround fails if there is data in the source table due
> to the initial null value placed in the existing data rows.
>
> [wcs1459@aclnx-cisp01 ~]$ psql --port=5433 -e -f x
> begin;
> BEGIN
> create table a (
> id seria
On Wed, Mar 7, 2012 at 11:45 AM, Mike Blackwell wrote:
>
> works for me -- what version are you on?
>
> merlin
>
> --
>
> [wcs1459@aclnx-cisp01 ~]$ psql --version
> psql (PostgreSQL) 9.1.1
> contains support for command-line editing
>
>
> [wcs1459@aclnx-cisp01 ~]$ cat x
> create table a (
>
On Wed, Feb 1, 2012 at 10:00 AM, Tom Lane wrote:
> o.bous...@krohne.com writes:
>> Should the query
>
>> select
>> extract(epoch
>> from cast('2012-01-01 14:30:1' as
>> timestamp) -
>> cast('1970-01-01 0:0:0' as
>> timestamp))) -
>> extract(epoch
>>
2011/12/27 wcting163 :
> postgres=# select version();
> version
>
> ---
> PostgreSQL 9.0alpha5 on x86_64-unknown-linux-
On Thu, Dec 29, 2011 at 2:10 PM, Tom Lane wrote:
> havasvolgyi.o...@gmail.com writes:
>> The following bug has been logged on the website:
>> Bug reference: 6365
>> Logged by: Otto Havasvölgyi
>> Email address: havasvolgyi.o...@gmail.com
>> PostgreSQL version: 9.1.2
>> Operating
On Thu, Oct 20, 2011 at 3:01 PM, Tom Lane wrote:
> Pavel Stehule writes:
>> I didn't design a PERFORM statement. There is two views - somebody
>> from sybase's family know so SELECT without into is forwarded to
>> client. This functionality is missing on Oracle's family. Is true so
>> PERFORM sta
On Thu, Oct 20, 2011 at 2:28 AM, Pavel Stehule wrote:
>>
>> it would be really a good idea to allow SELECT without INTO in plpgsql.
>
> SELECT without INTO is useless in plpgsql - because you have to drop result.
not if you're calling a function:
select func();
merlin
--
Sent via pgsql-bugs ma
On Wed, Oct 19, 2011 at 7:36 AM, Robert Haas wrote:
> On Tue, Sep 6, 2011 at 1:43 PM, Bruce Momjian wrote:
>> Well, this problem isn't isolated to WITH queries:
>>
>> test=> do
>> $$begin
>> perform(
>> select 1 UNION ALL select 1
>> );
>> end$$;
>>
On Mon, Oct 10, 2011 at 7:35 AM, Murilo - Perfilweb Informática
wrote:
> Hello,
> My encoding is LATIN1, my collation is pt_BR
> Thank You.
> 2011/10/7 Merlin Moncure
hm, LATIN1 is not a unicode supporting encoding, that might be
problem. your database should probably be defined U
On Fri, Oct 7, 2011 at 8:31 AM, Murilo Lobato wrote:
>
> The following bug has been logged online:
>
> Bug reference: 6244
> Logged by: Murilo Lobato
> Email address: mur...@perfilweb.com.br
> PostgreSQL version: 9.0.3
> Operating system: Centos 5.5
> Description: Order
On Thu, Sep 29, 2011 at 3:26 PM, Peter Geoghegan wrote:
> I've built Postgres from master, and found that the following fairly
> simple query breaks:
>
> select count(*)
> from
> (
> select
> schemaname
> from pg_stat_user_tables
> order by 1
> ) sub
>
On Wed, Sep 28, 2011 at 3:50 PM, Pierre Ducroquet wrote:
>
> The following bug has been logged online:
>
> Bug reference: 6232
> Logged by: Pierre Ducroquet
> Email address: p.p...@pinaraf.info
> PostgreSQL version: 9.1.1
> Operating system: Linux Debian, amd64
> Description:
On Wed, Sep 28, 2011 at 10:40 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from depstein's message of mié sep 28 07:21:17 -0300 2011:
>>> ALTER TYPE ... ADD VALUE does not work inside transaction blocks, period,
>>> whether they are executed as a multi-command string or one query at
On Wed, Sep 28, 2011 at 5:21 AM, wrote:
>> -Original Message-
>> From: Merlin Moncure [mailto:mmonc...@gmail.com]
>> Sent: Tuesday, September 27, 2011 10:31 PM
>> > 1. We can use ALTER TYPE to add enum values, but there is no matching
>> command to r
On Tue, Sep 27, 2011 at 5:06 AM, wrote:
> Hello,
>
> I've encountered some problems with the updated ENUM in PosgreSQL 9.1:
>
> 1. We can use ALTER TYPE to add enum values, but there is no matching command
> to remove values, which makes this an incomplete solution.
you can manually delete from
On Mon, Sep 26, 2011 at 11:08 AM, Robert Haas wrote:
> On Mon, Sep 26, 2011 at 11:40 AM, Robert Haas wrote:
>> To check my work, I did this:
>>
>> --- a/src/backend/executor/execQual.c
>> +++ b/src/backend/executor/execQual.c
>> @@ -5003,6 +5003,7 @@ ExecQual(List *qual, ExprContext *econtext, bo
On Tue, Sep 20, 2011 at 11:05 AM, Lionel Elie Mamane wrote:
>
> The following bug has been logged online:
>
> Bug reference: 6216
> Logged by: Lionel Elie Mamane
> Email address: lio...@mamane.lu
> PostgreSQL version: 9.1.0
> Operating system: Debian GNU/Linux
> Description:
On Tue, Sep 13, 2011 at 1:44 AM, Thomas Kellerer wrote:
> Merlin Moncure, 12.09.2011 21:28:
>>>
>>> With the second attempt, the installer again hang during initdb. Checking
>>> the state using ProcessExplorer I could see that the installer script was
>>> wa
On Mon, Aug 29, 2011 at 9:00 AM, Kevin Grittner
wrote:
> Merlin Moncure wrote:
>
>> yeah, that's the correct way, but why does this work?
>> select val from random() as val;
>
> If you look at the PostgreSQL reference docs for the SELECT
> statement, a from_i
On Mon, Aug 29, 2011 at 7:49 AM, Kevin Grittner
wrote:
> Alexey Klyukin wrote:
>
>> The following statement produces an error message in PostgreSQL 8.4
>> - 9.2 (head):
>>
>> postgres=# select val from random()::integer as val;
>
>> The same statement rewritten with CAST AS works as expected:
>>
On Thu, Jun 30, 2011 at 5:44 AM, Maxim Boguk wrote:
>
> The following bug has been logged online:
>
> Bug reference: 6087
> Logged by: Maxim Boguk
> Email address: maxim.bo...@gmail.com
> PostgreSQL version: 9.0
> Operating system: Linux
> Description: Unnest with multi
2011/6/17 Антон Степаненко :
>>
>> I wonder if you are oversubscribing your memory, and are getting weird
>> errors when reading data into memory because the pages can't be
>> reserved to do that. What happens when you enable overcommit and
>> attempt to start the server?
>>
>> merlin
>
> In my fi
2011/6/17 Антон Степаненко :
> 17.06.2011, 21:24, "Merlin Moncure" :
>> 2011/6/17 Антон Степаненко ;:
>>
>>> 17.06.2011, 20:19, "Merlin Moncure" ;:
>>>> On Fri, Jun 17, 2011 at 10:56 AM, Kevin Grittner
>>>> ;; wrote:
>&g
2011/6/17 Антон Степаненко :
>
>
> 17.06.2011, 20:19, "Merlin Moncure" :
>> On Fri, Jun 17, 2011 at 10:56 AM, Kevin Grittner
>> ; wrote:
>>
>>>> I still do not believe that this is hardware problem.
>>> How would an application caus
On Fri, Jun 17, 2011 at 10:56 AM, Kevin Grittner
wrote:
>> I still do not believe that this is hardware problem.
>
> How would an application cause a bus error?
unaligned memory access on risc maybe? what's this running on?
merlin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
On Mon, Feb 21, 2011 at 6:31 PM, Tom Lane wrote:
> I wrote:
>> Ugh. That quick little "ExecRemoveJunk" is a lot more dangerous than it
>> looks. I had actually looked at this before, but concluded it was OK
>> because I couldn't reproduce the problem with a trigger in place.
>> I guess I wasn't
On Fri, Jun 3, 2011 at 10:42 AM, Jehan-Guillaume (ioguix) de Rorthais
wrote:
>
> The following bug has been logged online:
>
> Bug reference: 6051
> Logged by: Jehan-Guillaume (ioguix) de Rorthais
> Email address: j...@dalibo.com
> PostgreSQL version: 9.1beta1
> Operating system
On Wed, May 25, 2011 at 9:06 AM, Merlin Moncure wrote:
> On Wed, May 25, 2011 at 7:37 AM, Craig Ringer
> wrote:
>> On 05/24/2011 07:05 PM, Paragon Corporation wrote:
>>>
>>> In regression testing PostGIS 2.0, our topology module regression tests
>>>
On Wed, May 25, 2011 at 7:37 AM, Craig Ringer
wrote:
> On 05/24/2011 07:05 PM, Paragon Corporation wrote:
>>
>> In regression testing PostGIS 2.0, our topology module regression tests
>> are
>> failing in PostgreSQL 9.1 beta.
>>
>> We have a PostGIS ticket open for it here, but we suspect it's a
>
On Fri, Apr 15, 2011 at 4:27 PM, Kevin Grittner
wrote:
> Merlin Moncure wrote:
>
>> There are lots of use cases for this. I use composite types to
>> marshal data to the client all the time, and recursive structures
>> are fairly common in many classic problems. Recursi
On Fri, Apr 15, 2011 at 3:49 PM, Kevin Grittner
wrote:
> I haven't seen anything which seems like a reasonable use case yet,
> myself. If you were *actually* tracking turtles and their
> offspring, that would be a completely worthless data structure. Is
> there really a case where a reference to
On Fri, Apr 15, 2011 at 1:34 PM, Rikard Pavelic
wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5982
> Logged by: Rikard Pavelic
> Email address: rikard.pave...@zg.htnet.hr
> PostgreSQL version: 9.1.alpha5
> Operating system: Windows XP SP3
> Descriptio
On Wed, Apr 13, 2011 at 12:29 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> I think you may have uncovered a leak (I stand corrected).
>
>> The number of schemas in your test is irrelevant -- the leak is
>> happening in proportion to the number of views (set via \setran
On Tue, Apr 12, 2011 at 12:48 PM, Shianmiin wrote:
>
> Merlin Moncure-2 wrote:
>>
>>
>> I am not seeing your results. I was able to run your test on a stock
>> config (cut down to 50 schemas though) on a vm with 512mb of memory.
>> What is your shared buffers
On Thu, Mar 24, 2011 at 10:36 AM, Pavel Stehule wrote:
> Hello
>
> why you can do it?
>
> please, try to RETURN QUERY ...
>
> Regards
>
> Pavel Stehule
>
>
>>
>> $$begin
>>
>> perform(
>>
>> with A as (select generate_series(1,3) as foo)
>>
>> select foo from A
>>
>> );
>>
>> end$$;
This is 'DO'
On Wed, Mar 23, 2011 at 8:10 AM, Donald Fraser wrote:
> - Original Message -
>
> Sent: Wednesday, March 23, 2011 12:50 PM
> Subject: Index Ignored Due To Use Of View
> PostgreSQL 8.3.14
> OS: Linux Redhat 5.4
>
> Note: I have used the same subject for this email taken from an email:
> Post
On Tue, Jan 25, 2011 at 12:01 PM, Murray S. Kucherawy
wrote:
>> -Original Message-
>> From: Robert Haas [mailto:robertmh...@gmail.com]
>> Sent: Tuesday, January 25, 2011 7:33 AM
>> To: Kevin Grittner
>> Cc: Murray S. Kucherawy; Tom Lane; pgsql-bugs@postgresql.org
>> Subject: Re: [BUGS] BU
On Thu, Mar 3, 2011 at 12:37 PM, Richard Neill wrote:
>
>> Sure it does. You can pass the tuple to RAISE NOTICE easily enough.
>> It won't have all the same bells and whistles psql would supply, but
>> it prints out well enough for debugging. Or at least it's never
>> bothered me.
>
> Sorry if I
On Thu, Mar 3, 2011 at 9:20 AM, Joshua McDougall wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5911
> Logged by: Joshua McDougall
> Email address: j...@schemaverse.com
> PostgreSQL version: 9.0.3
> Operating system: Slackware Linux Kernel 2.6.28.6
>
On Tue, Mar 1, 2011 at 12:50 PM, Matt Harrington
wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5905
> Logged by: Matt Harrington
> Email address: matt.harring...@rentrak.com
> PostgreSQL version: 8.4.3
> Operating system: CentOS 4.7
> Description:
On Tue, Mar 1, 2011 at 5:11 AM, Ingmar Brouns wrote:
> Hi Tom,
>
> thanks for your reply.
>
>>
>> > I was looking for a workaround to this problem, and figured that calling
>> > 'discard all', or 'discard plans' should do the trick.
>>
>> That's not a solution because the plancache module intentio
On Fri, Feb 25, 2011 at 9:48 AM, Merlin Moncure wrote:
> On Fri, Feb 25, 2011 at 9:40 AM, Alvaro Herrera
> wrote:
>> Excerpts from Merlin Moncure's message of vie feb 25 12:28:25 -0300 2011:
>>
>>> no I wouldn't, and the pg_dump extra_float_digits setting a
On Fri, Feb 25, 2011 at 9:40 AM, Alvaro Herrera
wrote:
> Excerpts from Merlin Moncure's message of vie feb 25 12:28:25 -0300 2011:
>
>> no I wouldn't, and the pg_dump extra_float_digits setting addresses my
>> primary concern. The client has a similar issue though -- suppose it
>> fetches a value
On Fri, Feb 25, 2011 at 9:21 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> right -- in understand how floating point works -- but are you are
>> saying that you are ok with the fact that (for example) a table with a
>> floating point unique key could dump and not restore?
On Thu, Feb 24, 2011 at 8:03 PM, Greg Stark wrote:
> On Thu, Feb 24, 2011 at 7:31 PM, Merlin Moncure wrote:
>> the root issue I think here is that the string version of the double
>> precision math is approximated:
>
> No, it's simpler than that, all double precision m
On Thu, Feb 24, 2011 at 1:01 PM, Nathan M. Davalos
wrote:
> I ran into something interesting with using trunc() and different data
> types:
>
> The following is a simplified from the statement we’re using and produces
> the same results:
>
> select trunc( ((cast(2183.68 as numeric) - cast(1 as num
On Thu, Nov 4, 2010 at 12:14 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Merlin Moncure wrote:
>>> Trying to understand real world cases that this would
>>> break...would the following now fail w/o explicit cast?
>>>
>>> create
On Fri, Oct 29, 2010 at 4:12 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Robert Haas wrote:
I think if I had to pick a proposal, I'd say we should disable #2
for the specific case of casting a composite type to something
else.
>
>>> Well, then let's do that. It's not the ex
On Wed, Aug 4, 2010 at 3:11 PM, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>>> If we were a bit earlier in the 9.0 cycle I would suggest that this
>>> confusion is a sufficient reason to drop the one-argument form of
>>> string_agg. It's too late now
Not 100% sure I have a bug, but I've never seen this before so I
though it was worth a post. Confirmed on 8.4.4 and 9.0 beta. I have
a small self contained test case that I can send off line or on the
list following some code obfuscation (it's fairly complex to set up).
merlin
--
Sent via pgs
The following functions fail:
create or replace function docopy(int[]) returns int as
$$
copy (select unnest($1)) to stdout;
select 0;
$$ language sql;
ERROR: there is no parameter $1
create or replace function docopy(int[]) returns int as
$$
begin
copy (select unnest($1)) to stdout;
e
On Thu, Sep 3, 2009 at 12:48 AM, Keith Cascio wrote:
> Pavel,
>
> On Thu, 3 Sep 2009, Pavel Stehule wrote:
>
>> it's not bug - PostgreSQL doesn't support parameter placeholder on this
>> position. Use dynamic query instead - plpgsql statement EXECUTE.
>
> Thank you for your reply. I appreciate you
On Tue, Sep 1, 2009 at 4:11 AM, Heikki
Linnakangas wrote:
> 2. The semantics of STRICT with row arguments is broken. It should be
> made consistent with IS NULL. Strict function should not be called if
> the argument is a row value with all NULL columns.
not just STRICT, but coalesce(), libpq 'is
On Fri, Aug 28, 2009 at 1:38 PM, Kevin
Grittner wrote:
> Merlin Moncure wrote:
>
>> This leads to some very weird behaviors, for example 'coalesce(foo,
>> something)' and 'case when foo is null then something else foo end'
>> can give different an
Today I ran into a problem relating to $subject. plpgsql's handling
of 'null' composite types is not consistent with what you get in sql:
create table foo(a text, b text);
create table bar(id int, f foo);
insert into bar values (1, ('a', 'b'));
create or replace function f(_foo out foo) returns
I _may_ have found a problem that is affecting non-greedy regex matches.
select regexp_matches(
$$x = foo y x = foo y $$,
$$x\s+(.*?)y$$ ,'g');
As I read it, this should match ' = foo' twice. Instead, it matches
"= foo y x = foo " once. The non-greedy form (.*?) should break out
at the fir
On 6/11/08, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> Rajesh Chopra wrote:
> > Hi,
> > I created a new type as follows:
> > CREATE TYPE compfoo AS (f1 int, f2 text);
> >
> > Now I need the DDL which postgres used to create this type.
> >
>
> Huh, what do you mean? That CREATE TYPE statement i
On Thu, May 8, 2008 at 12:27 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Andrew Chernow wrote:
> > >>> This is exactly what libpqtypes solves. Not only do we handle
> > >>> formatting of binary formats, we provide a level of protection from
> > >>> internal format changes for libpq users. S
Bruce Momjian wrote:
> This brings up a good question. Exactly how do users know what format
> _binary_ is? int4 is network byte order, but what about int8, float4,
> inet?
This is exactly what libpqtypes solves. Not only do we handle
formatting of binary formats, we provide a level of protecti
On 9/7/06, Nimesh Satam <[EMAIL PROTECTED]> wrote:
We also noticed that the database slow downs heavily at a particular
time..Can you suggest any tools which will help in diagnosing the root cause
behiond the data load.
possible checkpoint? poorly formulated query? it could be any number
of t
in the win2k environment, I would consider adding the path to the
Cygwin1.dll to the system path (for example, c:\cygwin\bin)
then, using command prompt shell, not the CYGWIN shell, cd to the folder
containing the ipc-daemon.
>From there, type ipc-daemon to run the daemon
or ipc-daemon --install-
85 matches
Mail list logo
