On Mon, 2008-04-21 at 21:08 +0100, Simon Riggs wrote:
> The following two files specify the behaviour of the MERGE statement and
> how it will work in the world of PostgreSQL.
> The HTML file was generated from SGML source, though the latter is not
> included here for clarity.
Enclose merge.sgml
On 05/08/10 10:46, Simon Riggs wrote:
On Mon, 2008-04-21 at 21:08 +0100, Simon Riggs wrote:
The following two files specify the behaviour of the MERGE statement and
how it will work in the world of PostgreSQL.
The HTML file was generated from SGML source, though the latter is not
included her
On 04/08/10 16:50, Andrew Dunstan wrote:
On 08/04/2010 09:29 AM, Heikki Linnakangas wrote:
All those issues can be avoided if you only run "git gc" when all the
working directories are in a clean state, with no staged but
uncommitted changes or other funny things. I can live with that gun
tied
On 05/08/10 05:08, Daniel Farina wrote:
On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas
wrote:
All those issues can be avoided if you only run "git gc" when all the
working directories are in a clean state, with no staged but uncommitted
changes or other funny things. I can live with that g
Tom Lane wrote:
Yeb Havinga writes:
A.a_columnB.a_column
| /
v v
C.a_column
C inherits from A and B.
Well, if A and B inherited the column from a common ancestor, he can
easily do that. If not, maybe he should have thought harder before he
started.
On Wed, Aug 4, 2010 at 10:00 PM, Robert Haas wrote:
> On Tue, Aug 3, 2010 at 1:50 PM, Kolb, Harald (NSN - DE/Munich)
> wrote:
>> Or is "fsync" still not supported ?
>
> Wouldn't you need to have it set to "apply" to get the behavior you want here?
Yes. In that case, replication_mode needs to be
On Wed, Aug 4, 2010 at 12:35 AM, Heikki Linnakangas
wrote:
> There's some race conditions with the signaling. If another process finishes
> XLOG flush and sends the signal when a walsender has just finished one
> iteration of its main loop, walsender will reset xlogsend_requested and go
> to sleep
On Thu, 2010-08-05 at 12:29 +0300, Heikki Linnakangas wrote:
> On 05/08/10 10:46, Simon Riggs wrote:
> > On Mon, 2008-04-21 at 21:08 +0100, Simon Riggs wrote:
> >> The following two files specify the behaviour of the MERGE statement and
> >> how it will work in the world of PostgreSQL.
> >
> >> The
On Thu, Aug 5, 2010 at 6:15 AM, Yeb Havinga wrote:
> Tom Lane wrote:
>>
>> Yeb Havinga writes:
>>
>>>
>>> A.a_column B.a_column
>>> | /
>>> v v
>>> C.a_column
>>> C inherits from A and B.
>>>
>>
>> Well, if A and B inherited the column from a common ancestor, he can
>>
I want to create a database backup when PG is running, so I call
pg_start_backup(''), scp the data to a backup directory, pg_stop_backup.
Then I reboot PG , PG boot failed with log like "unexpected pageaddr X/X in log
file X, segment X, offset X" "WAL ends before end time of backup dump".
Then
PS : I am using PG 8.3.7
--
Richard
2010-08-05
-
发件人：Richard
发送日期：2010-08-05 21:19:27
收件人：pgsql-hackers
抄送：
主题：Online backup cause boot failure, anyone know why?
I want to create a database
On 08/05/2010 09:19 AM, Richard wrote:
I want to create a database backup when PG is running, so I call
pg_start_backup(''), scp the data to a backup directory, pg_stop_backup.
Then I reboot PG , PG boot failed with log like "unexpected pageaddr X/X in log file X,
segment X, offset X" "WAL e
Michael Meskes wrote:
> All prior ECPG versions were fine because dynamic cursor names
> were only added in 9.0. Apparently only this one place was
> missed. So this is a bug in the new feature, however not such a
> major one that it warrants the complete removal IMO. I'd prefer to
> fix this in
I reboot PG because I found PG recovery end point if far away from the actual
end point of the XLOG on the backup directory, so I want to test if the
original DB is OK.
Unfortunately, I got the same PG log on the original DB. I don't unstand what
you said, I missing what?
---
On Thu, Aug 5, 2010 at 7:25 PM, Simon Riggs wrote:
> On Thu, 2010-08-05 at 12:29 +0300, Heikki Linnakangas wrote:
> > On 05/08/10 10:46, Simon Riggs wrote:
> > > On Mon, 2008-04-21 at 21:08 +0100, Simon Riggs wrote:
> > >> The following two files specify the behaviour of the MERGE statement
> and
pg_stat_user_functions has an inconsistent notion of what "user" is.
Whereas the other pg_stat_user_* views filter out non-user objects by
schema, pg_stat_user_functions checks for language "internal", which
does not successfully exclude builtin functions of language SQL. Is
there a reason for thi
Robert Haas writes:
> Yeb Havinga writes:
>> The root cause seems to center around multiple inheritance of the same
>> column without a common ancestor. Another way to approach the problem, is to
>> prevent the user to create a setup, i.e. when adding a column to B that
>> already exists in A, or
"Richard" writes:
> PS : I am using PG 8.3.7
I believe there's a related bug fix in 8.3.8.
BTW, -hackers is not the place for this type of question.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
On Thu, Aug 5, 2010 at 9:50 AM, Richard wrote:
> I reboot PG because I found PG recovery end point if far away from the
> actual end point of the XLOG on the backup directory, so I want to test if
> the original DB is OK.
> Unfortunately, I got the same PG log on the original DB. I don't unsta
On Fri, Jul 30, 2010 at 7:02 AM, Jan Urbański wrote:
> On 24/07/10 15:20, Adriano Lange wrote:
>>
>> Hi,
>
> Hi!
>
>>
>> I'd like to release the last version of my experimental join order
>> algorithm (TwoPO - Two Phase Optimization [1]):
>>
>> http://git.c3sl.ufpr.br/gitweb?p=lbd/ljqo.git;a=summa
On Thu, Aug 5, 2010 at 9:59 AM, Tom Lane wrote:
> Well, if it were only a hint, and thus didn't actually "prevent"
> anything, then it wouldn't be breaking compatibility. But I don't
> like the idea much either. It would be extremely expensive, if not
> impossible, to determine whether all paren
Thanks for replying.
But I could not find any relation between the RequestXLogSwitch function and
the error I met.
For perfromance purpose , I change the pg_start_backup checkpoint type from
CHECKPOINT_WAIT to CHECKPOINT_IMMEDIATE, does it matter?
--
On Thu, Aug 05, 2010 at 04:58:32PM +0300, Peter Eisentraut wrote:
> pg_stat_user_functions has an inconsistent notion of what "user" is.
> Whereas the other pg_stat_user_* views filter out non-user objects
> by schema, pg_stat_user_functions checks for language "internal",
> which does not successf
On Wed, Aug 4, 2010 at 10:38 PM, Heikki Linnakangas
wrote:
> Then you risk running out of disk space. Similar to having an archive
> command that fails for some reason.
>
> That's one reason the registration should not be too automatic - there is
> serious repercussions if the standby just disappe
Oh sorry, I missed something. I turned off the XLOG archive in code after
pg_start_backup so the pg_xlog directory contains all the xlog files.
And for performance purpose, I change the checkpoint type in pg_start_backup to
CHECKPOINT_IMMEDIATE, does it matter?
The PG log I mentioned above is th
On Thu, Aug 05, 2010 at 09:55:29PM +0800, Boxuan Zhai wrote:
> On Thu, Aug 5, 2010 at 7:25 PM, Simon Riggs wrote:
>
> > On Thu, 2010-08-05 at 12:29 +0300, Heikki Linnakangas wrote:
> > > On 05/08/10 10:46, Simon Riggs wrote:
> > > > On Mon, 2008-04-21 at 21:08 +0100, Simon Riggs wrote:
> > > >> T
Thanks for replying.
But I could't find relation between the RequestXLogSwitch function and the
error I met.
For perfromance purpose , I change the pg_start_backup checkpoint type from
CHECKPOINT_WAIT to CHECKPOINT_IMMEDIATE, does it matter?
--
Ri
On Thu, 2010-08-05 at 21:55 +0800, Boxuan Zhai wrote:
> In the contrary, Simon's instruction says that the DEFAULT action for
> the tuple caught by no actions is
> WHEN NOT MATCHED THEN INSERT DEFAULT VALUES
>
> From the user's point of view, these two kinds of MERGE command may
> have not much
On Thu, Aug 5, 2010 at 10:20 AM, Richard wrote:
> Oh sorry, I missed something. I turned off the XLOG archive in code after
> pg_start_backup so the pg_xlog directory contains all the xlog files.
> And for performance purpose, I change the checkpoint type in pg_start_backup
> to CHECKPOINT_IMMED
Kevin Grittner írta:
> Michael Meskes wrote:
>
>> All prior ECPG versions were fine because dynamic cursor names
>> were only added in 9.0. Apparently only this one place was
>> missed. So this is a bug in the new feature, however not such a
>> major one that it warrants the complete removal I
"Richard" writes:
> For perfromance purpose , I change the pg_start_backup checkpoint type from
> CHECKPOINT_WAIT to CHECKPOINT_IMMEDIATE, does it matter?
Oh, so this isn't so much "8.3.7" as "randomly-hacked-up 8.3.7".
Yes, that'd break it, I believe. CHECKPOINT_IMMEDIATE doesn't imply
waiti
Thanks for your patience.
I use XLogCtl->Insert.forcePageWrites for XLOG recycling flag. So after
pg_start_backup, no more XLOG files will be recycled. And as I said above,
I make a CHECKPOINT_IMMEDIATE checkpoint in pg_start_backup, instead
CHECKPOINT_WAIT. That all I did to code.
I wonder wh
I am sorry, my English is poor.
I was confused by what you said.
What do you mean by saying "that'd break it"!
--
Richard
2010-08-05
-
发件人：Tom Lane
发送日期：2010-08-05 22:44:50
收件人：Richard
抄送：
I am sorry, my English is poor.
I was confused by what you said.
What do you mean by saying "that'd break it"!
--
Richard
2010-08-05
-
发件人：Tom Lane
发送日期：2010-08-05 22:44:50
收件人：Richard
抄送：
On Thu, Aug 05, 2010 at 04:46:51PM +0200, Pavel Stehule wrote:
> So Joshua, can you look on code?
Sure... thanks :)
--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com
signature.asc
Description: Digital signature
On 05/08/10 17:22, Simon Riggs wrote:
On Thu, 2010-08-05 at 21:55 +0800, Boxuan Zhai wrote:
In the contrary, Simon's instruction says that the DEFAULT action for
the tuple caught by no actions is
WHEN NOT MATCHED THEN INSERT DEFAULT VALUES
From the user's point of view, these two kinds of MER
On 05/08/10 17:56, Richard wrote:
> I am sorry, my English is poor.
> I was confused by what you said.
> What do you mean by saying "that'd break it"!
Replacing CHECKPOINT_WAIT with CHECKPOINT_IMMEDIATE broke it. Don't do that.
If you want to change the behavior of pg_start_backup() to perform
I found other issue :(
postgres=# select name, place from cars group by grouping sets(name, place,());
name | place
---+
bmw |
skoda |
opel |
| germany
| czech rep.
skoda | czech rep.
skoda | germany
bmw | czech rep.
bmw | germany
opel | czech rep
On Thu, 2010-08-05 at 18:17 +0300, Heikki Linnakangas wrote:
> On 05/08/10 17:22, Simon Riggs wrote:
> > On Thu, 2010-08-05 at 21:55 +0800, Boxuan Zhai wrote:
> >
> >> In the contrary, Simon's instruction says that the DEFAULT action for
> >> the tuple caught by no actions is
> >> WHEN NOT MATCHED
All jods are done by client code, not manually.
I still did't not understand what you said.
What break what?
Thandks!
--
Richard
2010-08-05
-
发件人：Heikki Linnakangas
发送日期：2010-08-05 23:21:54
On Thu, Aug 5, 2010 at 11:35 AM, Simon Riggs wrote:
> * It appears we would be in violation of the standard on
> 14.12 General Rule 6 a) i) 2) B), p.890
> (Oh, I wish I was joking, there really is such a paragraph number)
Just shoot me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
T
I need suggestion about how region based memory management is done in
postgres. I know the concept of region based memory management and also
know about the functions like memorycontextswitch().
But I am not understanding how Postgres uses hierarchical, region-based
memory management. That is I a
Sorry I thought Zoltan's explanation was clear enough. All prior ECPG versions
were fine because dynamic cursor names were only added in 9.0. Apparently only
this one place was missed. So this is a bug in the new feature, however not
such a major one that it warrants the complete removal IMO. I'
2010/8/5 Richard :
> All jods are done by client code, not manually.
What is a jod?
> I still did't not understand what you said.
> What break what?
The fact that you replaced CHECKPOINT_WAIT with CHECKPOINT_IMMEDIATE
is the cause of your problem. You "broke" the correctness of the
system by do
Looks like MERGE is progressing well.
At 2010 Dev Mtg, we put me down to work on making merge work
concurrently. That was garbled slightly and had me down as working on
predicate locking which is the general solution to the problem.
Do we still need me to work on concurrent MERGE, or is that inc
On Thu, Aug 5, 2010 at 7:25 AM, Simon Riggs wrote:
> Also had these fragments as well, if they're still useful. Probably just
> useful as pointers as to what else to change to include the docs.
>
>
> The tests and docs were written from SQL standard, so any deviations
> would need to be flagged. T
Sorry, wrong word, it should be job.
You mean the wrong type of checkpoint causes XLOG file recovery fail?
I was confused, the XLOG files seem corrupted, is it also caused by the
checkpoint type? If so , why it can do this?
--
Richard
2010-08-05
---
Excerpts from Michael Meskes's message of jue ago 05 05:39:46 -0400 2010:
> Sorry I thought Zoltan's explanation was clear enough. All prior ECPG
> versions were fine because dynamic cursor names were only added in 9.0.
> Apparently only this one place was missed. So this is a bug in the new
> f
On Thu, Aug 5, 2010 at 11:43 AM, Simon Riggs wrote:
> Looks like MERGE is progressing well.
>
> At 2010 Dev Mtg, we put me down to work on making merge work
> concurrently. That was garbled slightly and had me down as working on
> predicate locking which is the general solution to the problem.
>
>
Alvaro Herrera írta:
> Excerpts from Michael Meskes's message of jue ago 05 05:39:46 -0400 2010:
>
>> Sorry I thought Zoltan's explanation was clear enough. All prior ECPG
>> versions were fine because dynamic cursor names were only added in 9.0.
>> Apparently only this one place was missed. S
On 05/08/10 18:43, Simon Riggs wrote:
Do we still need me to work on concurrent MERGE, or is that included in
the current MERGE patch (can't see it), or ...
It's not in the current MERGE patch.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mail
sub...@cse.iitb.ac.in writes:
> I need suggestion about how region based memory management is done in
> postgres.
Have you read src/backend/utils/mmgr/README ? It's old but still
reasonably accurate.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacker
On 05/08/10 18:57, Robert Haas wrote:
On Thu, Aug 5, 2010 at 11:43 AM, Simon Riggs wrote:
Looks like MERGE is progressing well.
At 2010 Dev Mtg, we put me down to work on making merge work
concurrently. That was garbled slightly and had me down as working on
predicate locking which is the gene
Boszormenyi Zoltan writes:
> Alvaro Herrera Ãrta:
>> Since we're still in the beta phase, it makes sense to apply the fix
>> right now so that it appears in 9.0. No point in waiting for 9.0.1.
> It boils down to the fact that Michael doesn't have too much time
> and no one else knows ECPG in de
Let's be clear. If you change the postgres code and then things break I
think you're pretty much on your own. We can accept some responsibility
for helping you if you're running our code, but not if you're running
our code which you have subsequently mangled. If you break things you
get to fi
Heikki Linnakangas wrote:
>> However, I confess to ignorance as to the underlying
>> issues? Why is MERGE worse in this regard than, say, UPDATE?
>
> MERGE can be used to implement "upsert", where a row is updated if
> it exists and inserted if it doesn't. I don't think Kevin's patch
> will s
robertmh...@gmail.com (Robert Haas) writes:
> On Thu, Aug 5, 2010 at 11:43 AM, Simon Riggs wrote:
>> Looks like MERGE is progressing well.
>>
>> At 2010 Dev Mtg, we put me down to work on making merge work
>> concurrently. That was garbled slightly and had me down as working on
>> predicate lockin
mmonc...@gmail.com (Merlin Moncure) writes:
> On Wed, Aug 4, 2010 at 9:31 PM, Robert Haas wrote:
>> On Wed, Aug 4, 2010 at 6:43 PM, Merlin Moncure wrote:
>>> *) also, isn't it possible to change text cast influencing GUCs 'n'
>>> times per statement considering any query can call a function and a
http://groups.yahoo.com/group/syrilalwinl/message
n Bayern 646
Ludwig III. von Bayern: Gesuch Hitlers an L. 179
Lueger, Dr. Karl, BegrunderderChristlich-sozialen Partei (s. diese): L. und die
Christlich-soziale Partei
On Thu, Aug 5, 2010 at 12:59 PM, Chris Browne wrote:
> mmonc...@gmail.com (Merlin Moncure) writes:
>> On Wed, Aug 4, 2010 at 9:31 PM, Robert Haas wrote:
>>> On Wed, Aug 4, 2010 at 6:43 PM, Merlin Moncure wrote:
*) also, isn't it possible to change text cast influencing GUCs 'n'
times p
Chris Browne writes:
> mmonc...@gmail.com (Merlin Moncure) writes:
>> yeah -- perhaps you shouldn't be allowed set things like datestyle in
>> functions then.
> That would cause grief for Slony-I, methinks, and probably other things
> that behave somewhat similar.
Yeah, it's not really practical
Chris Browne wrote:
> robertmh...@gmail.com (Robert Haas) writes:
>> I suspect Kevin's patch will solve it if using a sufficiently
>> high transaction isolation level, but something else might be
>> needed otherwise. However, I confess to ignorance as to the
>> underlying issues? Why is MERGE
> At 2010 Dev Mtg, we put me down to work on making merge work
> concurrently. That was garbled slightly and had me down as working on
> predicate locking which is the general solution to the problem.
Well, we *still* want predicate locking regardless of what MERGE
supports. It's useful in about
I wrote:
> So... No, it's not directly a problem on the server itself.
I just had a thought -- the MERGE code isn't doing anything fancy
with snapshots, is it? I haven't been tracking that discussion too
closely or read the patch. My previous comments assume that the
*snapshot* is stable for
Attached is a patch to remove the upsert example from the pl/pgsql
documentation. It has a serious bug (see:
http://www.spinics.net/lists/pgsql/msg112560.html) which is nontrivial
to fix. IMNSHO, our code examples should encourage good practices and
style.
The 'correct' way to do race free upser
Robert Haas wrote:
> On Wed, Jul 28, 2010 at 1:20 AM, Mike Lewis
> wrote:
>>>
>>> > 1. As-is, it's a significant *pessimization* for small arrays,
>>> > because the heap_tuple_untoast_attr_slice code does a
>>> > palloc/copy even when one is not needed because the data is
>>> > already not toaste
On 8/5/10 6:58 AM, Peter Eisentraut wrote:
> pg_stat_user_functions has an inconsistent notion of what "user" is.
> Whereas the other pg_stat_user_* views filter out non-user objects by
> schema, pg_stat_user_functions checks for language "internal", which
> does not successfully exclude builtin fu
On Thu, Aug 5, 2010 at 12:59 PM, Chris Browne wrote:
> mmonc...@gmail.com (Merlin Moncure) writes:
>> On Wed, Aug 4, 2010 at 9:31 PM, Robert Haas wrote:
>>> On Wed, Aug 4, 2010 at 6:43 PM, Merlin Moncure wrote:
*) also, isn't it possible to change text cast influencing GUCs 'n'
times p
Merlin Moncure wrote:
> Attached is a patch to remove the upsert example from the pl/pgsql
> documentation. It has a serious bug (see:
> http://www.spinics.net/lists/pgsql/msg112560.html) which is
> nontrivial to fix. IMNSHO, our code examples should encourage
> good practices and style.
>
>
I started taking a look at the internals of the detoast functions and I came
to the conclusion that I didn't have sufficient understanding of what was
going on to make the correct changes, nor sufficient time to gain that
understanding. Sorry for not getting back sooner. There are a lot of
differ
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Attached is a patch to remove the upsert example from the pl/pgsql
> documentation. It has a serious bug (see:
> http://www.spinics.net/lists/pgsql/msg112560.html) which is nontrivial
> to fix. IMNSHO, our code examples should encourage good
Merlin Moncure writes:
> Attached is a patch to remove the upsert example from the pl/pgsql
> documentation. It has a serious bug (see:
> http://www.spinics.net/lists/pgsql/msg112560.html) which is nontrivial
> to fix. IMNSHO, our code examples should encourage good practices and
> style.
I was
mmonc...@gmail.com (Merlin Moncure) writes:
> On Thu, Aug 5, 2010 at 12:59 PM, Chris Browne wrote:
>> mmonc...@gmail.com (Merlin Moncure) writes:
>>> On Wed, Aug 4, 2010 at 9:31 PM, Robert Haas wrote:
On Wed, Aug 4, 2010 at 6:43 PM, Merlin Moncure wrote:
> *) also, isn't it possible to
On 08/05/2010 02:09 PM, Tom Lane wrote:
Merlin Moncure writes:
Attached is a patch to remove the upsert example from the pl/pgsql
documentation. It has a serious bug (see:
http://www.spinics.net/lists/pgsql/msg112560.html) which is nontrivial
to fix. IMNSHO, our code examples should encoura
I wrote:
> Well, I forgot that an aggregate involves more than one catalog row ;-).
> So it's a bit bigger patch than that, but still pretty small and safe.
> See attached.
Applied to HEAD and 9.0. The mistaken case will now yield this:
regression=# select string_agg(f1 order by f1, ',') from te
On ons, 2010-08-04 at 18:19 -0400, Tom Lane wrote:
>
> This policy also implies that we are never going to allow default
> arguments for aggregates, or at least never have any built-in ones
> that use such a feature.
>
> By my count the following people had offered an opinion on making
> this cha
Peter Eisentraut writes:
> I vote against this patch. There are plenty of other places that SQL is
> confusing, and this move seems excessive to me, and I find the
> functionality that is proposed for removal quite useful.
Huh? The functionality proposed for removal is only that of omitting an
On Aug 5, 2010, at 11:25 AM, Tom Lane wrote:
> Applied to HEAD and 9.0. The mistaken case will now yield this:
>
> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
> ERROR: function string_agg(text) does not exist
> LINE 1: select string_agg(f1 order by f1, ',') from text_tbl;
"Kevin Grittner" wrote:
New numbers on where we are with this CommitFest, at the end of the
third week:
72 patches were submitted
3 patches were withdrawn (deleted) by their authors
12 patches were moved to CommitFest 2010-09
--
57 patches in CommitFest 2010-07
--
3 committed to 9.0
--
54 pa
On 5 August 2010 19:39, David E. Wheeler wrote:
> On Aug 5, 2010, at 11:25 AM, Tom Lane wrote:
>
>> Applied to HEAD and 9.0. The mistaken case will now yield this:
>>
>> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
>> ERROR: function string_agg(text) does not exist
>> LINE
On Thu, Aug 5, 2010 at 12:25, Tom Lane wrote:
> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
> ERROR: function string_agg(text) does not exist
> LINE 1: select string_agg(f1 order by f1, ',') from text_tbl;
> ^
> HINT: No function matches the given name and ar
On Thu, Aug 5, 2010 at 2:09 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> Attached is a patch to remove the upsert example from the pl/pgsql
>> documentation. It has a serious bug (see:
>> http://www.spinics.net/lists/pgsql/msg112560.html) which is nontrivial
>> to fix. IMNSHO, our code examp
"David E. Wheeler" writes:
> On Aug 5, 2010, at 11:25 AM, Tom Lane wrote:
>> Applied to HEAD and 9.0. The mistaken case will now yield this:
>> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
>> ERROR: function string_agg(text) does not exist
> I'm confused: that looks like t
On Aug 5, 2010, at 11:42 AM, Thom Brown wrote:
>>> LINE 1: select string_agg(f1 order by f1, ',') from text_tbl;
>>> ^
>>
>> I'm confused: that looks like the two-argument form to me. Have I missed
>> something?
>>
>>> HINT: No function matches the given name and argument types.
On Aug 5, 2010, at 11:45 AM, Tom Lane wrote:
>> I'm confused: that looks like the two-argument form to me. Have I missed
>> something?
>
> Yeah, the whole point of the thread: that's not a call of a two-argument
> aggregate. It's a call of a one-argument aggregate, using a two-column
> sort key
Merlin Moncure writes:
> On Thu, Aug 5, 2010 at 2:09 PM, Tom Lane wrote:
>> I was not persuaded that there's a real bug in practice. IMO, his
>> problem was a broken trigger not broken upsert logic. Even if we
>> conclude this is unsafe, simply removing the example is of no help to
>> anyone.
> Well, maybe we need to expend some more sweat on the error message then.
> But this patch was still a prerequisite thing, because without it there
> is no error that we can complain about.
Yes, I'd say an addition to the HINT is in order *assuming* at that
stage we can tell if the user passed a
Josh Berkus writes:
>> Well, maybe we need to expend some more sweat on the error message then.
>> But this patch was still a prerequisite thing, because without it there
>> is no error that we can complain about.
> Yes, I'd say an addition to the HINT is in order *assuming* at that
> stage we ca
On Thu, Aug 5, 2010 at 3:16 PM, Tom Lane wrote:
> Josh Berkus writes:
>>> Well, maybe we need to expend some more sweat on the error message then.
>>> But this patch was still a prerequisite thing, because without it there
>>> is no error that we can complain about.
>
>> Yes, I'd say an addition
On Aug 5, 2010, at 12:16 PM, Tom Lane wrote:
> HINT: No aggregate function matches the given name and argument
> types. Perhaps you misplaced ORDER BY; ORDER BY must appear after all
> regular arguments of the aggregate.
+1
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
Robert Haas writes:
> On Thu, Aug 5, 2010 at 3:16 PM, Tom Lane wrote:
>> Next question: exactly how should the variant HINT be phrased?
>> I'm inclined to drop the bit about explicit casts and make it read
>> something like
>>
>> HINT: No aggregate function matches the given name and argument
>>
On 8/5/10 12:18 PM, Robert Haas wrote:
> Could we arrange to emit this error message only when there is an
> aggregate with the same name but different arguments?
Personally, I don't see this as really necessary. Just mentioning ORDER
BY in the hint will be enough to give people the right place t
Josh Berkus wrote:
> Well, we *still* want predicate locking regardless of what MERGE
> supports. It's useful in about 9 different ways.
I don't know whether this is the right time to discuss those 9
different uses, but just so everyone knows, the SIRead locks needed
for the SSI implementatio
On 8/5/10 12:33 PM, Kevin Grittner wrote:
> I don't know whether this is the right time to discuss those 9
> different uses, but just so everyone knows, the SIRead locks needed
> for the SSI implementation in the current serializable patch have
> some characteristics which may be exactly what you
Josh Berkus writes:
> On 8/5/10 12:18 PM, Robert Haas wrote:
>> Could we arrange to emit this error message only when there is an
>> aggregate with the same name but different arguments?
> Personally, I don't see this as really necessary. Just mentioning ORDER
> BY in the hint will be enough to
Josh Berkus wrote:
> Anyway, here's some of the uses I'm thinking of:
>
> (1) Pre-insert lock: you know that you're going to insert a record
> with PK="X" later in a long-running SP, so you want to lock out
> other inserts of PK="X" at the beginning of the procedure.
Well, if we added a liste
On tor, 2010-08-05 at 14:38 -0400, Tom Lane wrote:
> Huh? The functionality proposed for removal is only that of omitting
> an explicit delimiter argument for string_agg(). Since the default
> value (an empty string) doesn't seem to be the right thing all that
> often anyway, I'm not following wh
Kevin,
Overall, you're missing the point: there are workarounds for all of
these things now. However, they are *workarounds*, which means that
they are awkward, expensive, and/or hard to administrate; having
predicate locks would make things much easier.
> I don't see how that can be resolved wi
There's a little problem with EXECUTE USING when the parameters are of
type unknown (going back to 8.4 where EXECUTE USING was introduced):
do $$
BEGIN
EXECUTE 'SELECT to_date($1, $2)' USING '17-DEC-80', 'DD-MON-YY';
END;
$$;
ERROR: failed to find conversion function from unknown to text
CONT
Hello
2010/8/5 Heikki Linnakangas :
> There's a little problem with EXECUTE USING when the parameters are of type
> unknown (going back to 8.4 where EXECUTE USING was introduced):
>
> do $$
> BEGIN
> EXECUTE 'SELECT to_date($1, $2)' USING '17-DEC-80', 'DD-MON-YY';
> END;
> $$;
> ERROR: failed to
1 - 100 of 125 matches
Mail list logo
