On sön, 2009-11-22 at 16:03 -0800, David Fetter wrote:
> What, if anything, does the standard have to say about violations of
> ASSERTIONs? I know these aren't ASSERTIONs, but they much more
> closely resemble them than they do UNIQUE constraints.
An assertion is by definition a constraint that i
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
Remove -w (--ignore-all-space) option from pg_regress's diff calls.
Looks like this has broken on Windows due to different line endings,
which -w hid from us.
Yeah. I was waiting for brown_bat to report in be
On Sun, Nov 22, 2009 at 10:41 PM, Craig Ringer
wrote:
> Tom Lane wrote:
> It'd be a HUGE benefit in deployment and update scripts to have PL/PgSQL
> installed and available by default, at least to the superuser and to
> the DB owner.
Are there any known security problems with plpgsql?
--
Sent
Tom Lane wrote:
> Andrew Dunstan writes:
>> Part of the motivation for allowing inline blocks was to allow for
>> conditional logic.
>
> I don't think that argument really applies to this case, because the
> complaint was about not being sure if plpgsql is installed. If it
> isn't, you can hard
On Sun, Nov 22, 2009 at 10:19 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Part of the motivation for allowing inline blocks was to allow for
>> conditional logic.
>
> I don't think that argument really applies to this case, because the
> complaint was about not being sure if plpgsql is instal
Andrew Dunstan writes:
> Tom Lane wrote:
>> Remove -w (--ignore-all-space) option from pg_regress's diff calls.
> Looks like this has broken on Windows due to different line endings,
> which -w hid from us.
Yeah. I was waiting for brown_bat to report in before bringing this
up on the list, bec
Andrew Dunstan writes:
> Part of the motivation for allowing inline blocks was to allow for
> conditional logic.
I don't think that argument really applies to this case, because the
complaint was about not being sure if plpgsql is installed. If it
isn't, you can hardly use a plpgsql DO block to
Tom Lane wrote:
[ thinks for awhile... ] Actually, CREATE LANGUAGE is unique among
creation commands in that the common cases have no parameters, at least
not since we added pg_pltemplate. So you could imagine defining CINE
for a language as disallowing any parameters and having these semanti
Robert Haas writes:
> On Sun, Nov 22, 2009 at 6:51 PM, Tom Lane wrote:
>> CREATE IF NOT EXISTS has been proposed and rejected before, more than
>> once. Please see the archives.
> Search for CINE to find the discussions. This is a good place to start:
> http://archives.postgresql.org/pgsql-hac
On Sun, Nov 22, 2009 at 6:51 PM, Tom Lane wrote:
> Craig Ringer writes:
>> I do think this comes up often enough that a built-in trigger "update
>> named column with result of expression on insert" trigger might be
>> desirable.
>
> There's something of the sort in contrib already, I believe, tho
On Sun, Nov 22, 2009 at 12:35 PM, Jan Urbański wrote:
> I was thinking more about SGML docs. They could mention that BEFORE
> triggers are fired both for the parent table and for the child table,
> while AFTER triggers will only be called on the target table. I'd add a
> sentence or two explaining
Greg Stark writes:
> ISTM the danger is that someone looks at the regular logs and isn't
> aware that some messages went to someplace else. In which case
> bleating to the someplace else is unhelpful.
Yes, that's my problem with it in a nutshell. Anybody who is smart
enough to look at the origin
Hi.
Only for CVS-HEAD, not need backpatch.
I checked REL8_4_STABLE is this.
==
nmake -f win32.mak
...
Microsoft (R) Manifest Tool version 5.2.3790.2076
Copyright (c) Microsoft Corporation 2005.
All rights reserved.
cd ..\..
echo All Win32 parts have been built!
All Win32 parts have
> MySQL had the following syntax available:
> `updated_date` timestamp NOT NULL default CURRENT_TIMESTAMP on update
> CURRENT_TIMESTAMP
I wonder supporting this syntax would speed things up a little bit.
Here's a simple benchmark about the situation we are discussing here:
There are 2 tables:
On Fri, Nov 20, 2009 at 01:36:59PM +0900, Josh Berkus wrote:
> RObert,
>
> > I guess I'm going to have to vote -1 on this proposal. I code see
> > inventing a pgsql-specific SQLSTATE value for exclusion constraints,
> > since they will be a pgsql-specific extension, but reusing the unique
> > key
Craig Ringer writes:
> I do think this comes up often enough that a built-in trigger "update
> named column with result of expression on insert" trigger might be
> desirable.
There's something of the sort in contrib already, I believe, though
it's so old it still uses abstime :-(
> So might "CRE
2009/11/22 Craig Ringer
> On 23/11/2009 4:15 AM, Scott Marlowe wrote:
> > On Sun, Nov 22, 2009 at 12:50 PM, Thom Brown
> wrote:
> >> Hi,
> >> This should be simple, but for some reason I'm not quite sure what the
> >> solution is. I want to be able to update the value of a column for rows
> >>
On 23/11/2009 4:15 AM, Scott Marlowe wrote:
> On Sun, Nov 22, 2009 at 12:50 PM, Thom Brown wrote:
>> Hi,
>> This should be simple, but for some reason I'm not quite sure what the
>> solution is. I want to be able to update the value of a column for rows
>> that have been updated. More specifical
Tom Lane wrote:
Andrew Dunstan writes:
I put the attached together a while ago and neglected to send it.
Basically it includes the text of the query being explained in the
explain output.
I'm pretty certain this will dump core in some contexts --- you should
not assume that sourceT
On Sun, 22 Nov 2009, Emmanuel Cecchet wrote:
> Stephan Szabo wrote:
> > On Sun, 22 Nov 2009, Emmanuel Cecchet wrote:
> >
> >
> >> As I explained to Tom, if the after row trigger is called asynchronously
> >> I get a relcache leak on the child table at the end of the copy
> >> operation. If the tr
Stephan Szabo wrote:
On Sun, 22 Nov 2009, Emmanuel Cecchet wrote:
As I explained to Tom, if the after row trigger is called asynchronously
I get a relcache leak on the child table at the end of the copy
operation. If the trigger is called synchronously (like a before row
trigger) it works fi
On Thu, Nov 19, 2009 at 3:50 AM, Andrew Dunstan wrote:
> I'm fine with that. I don't remember whether I put that in or whether it
> came from the original patch author(s). Either way, I assume the reason was
> to explain why the message appeared on stderr rather than the CSVlog. Now we
> have a co
Andrew Dunstan writes:
> I put the attached together a while ago and neglected to send it.
> Basically it includes the text of the query being explained in the
> explain output.
I'm pretty certain this will dump core in some contexts --- you should
not assume that sourceText is always available
On Sun, 22 Nov 2009, Emmanuel Cecchet wrote:
> As I explained to Tom, if the after row trigger is called asynchronously
> I get a relcache leak on the child table at the end of the copy
> operation. If the trigger is called synchronously (like a before row
> trigger) it works fine. Also calling t
I put the attached together a while ago and neglected to send it.
Basically it includes the text of the query being explained in the
explain output.
I think it's more important to include the query text when using
auto_explain than in other explain uses, which is why I did it this way.
But
2009/11/22 Hiroshi Saito :
> Hi Magnus.
>
> It is a thing left behind.:-)
> please apply it. Thanks!
> ==
> libpq.lib(ip.obj) : error LNK2019: 未解決の外部シンボル __imp__wsaio...@36 が関
> 数 _pg_foreach_ifaddr で参照されました。
> libpq.lib(ip.obj) : error LNK2019: 未解決の外部シンボル __imp__wsasock...@24 が
> 関数 _pg_foreach_if
Emmanuel Cecchet wrote:
> Jan,
>
>> A couple of nitpicks first:
>>
>> o) the route_tuple_to_child recurses to child tables of child tables,
>> which is undocumented and requires a check_stack_depth() call if it's
>> really desirable
>>
> The recursive call is as deep as the inheritance hierarc
Heikki Linnakangas writes:
> Jan UrbaÅski wrote:
>> ISTM that there's a superfluous curly brace in print_path (which only
>> gets compiled with -DOPTIMIZER_DEBUG.
> Thanks, committed.
You know, the last couple of times I've touched that code, I've been
wondering why we bother to maintain it. P
Jan Urbański wrote:
> ISTM that there's a superfluous curly brace in print_path (which only
> gets compiled with -DOPTIMIZER_DEBUG.
>
> Patch attached.
Thanks, committed.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Hi Magnus.
It is a thing left behind.:-)
please apply it.
Thanks!
==
libpq.lib(ip.obj) : error LNK2019: 未解決の外部シンボル __imp__wsaio...@36 が関
数 _pg_foreach_ifaddr で参照されました。
libpq.lib(ip.obj) : error LNK2019: 未解決の外部シンボル __imp__wsasock...@24 が
関数 _pg_foreach_ifaddr で参照されました。
==
Regards,
Hiroshi Saito
Hi,
ISTM that there's a superfluous curly brace in print_path (which only
gets compiled with -DOPTIMIZER_DEBUG.
Patch attached.
Jan
diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c
index bfadcb0..6b2f86c 100644
--- a/src/backend/optimizer/path/allpaths.c
31 matches
Mail list logo
