On Tue, 14 Aug 2012 10:50:07 -0700
Josh Berkus j...@agliodbs.com wrote:
Yeah, I think there's more people that agree with this use-case
than you seem to think.. That said, I appreciate that it's not a
trivial thing to support cleanly.
Not trivial, no, but not major either. Really
Hello
2012/9/19 Shigeru HANADA shigeru.han...@gmail.com:
On Fri, Aug 10, 2012 at 3:21 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
there is new version of this patch
* cleaned var list parser
* new regress tests
* support FETCH_COUNT 0
Here are my review comments.
Submission
Hi Pavel,
(2012/09/21 2:01), Pavel Stehule wrote:
- Is it intentional that \gset can set special variables such as
AUTOCOMMIT and HOST? I don't see any downside for this behavior,
because \set also can do that, but it is not documented nor tested at all.
I use a same SetVariable function,
Hi,
I'm sakamoto, maintainer of reorg.
What could be also great is to move the project directly into github to
facilitate its maintenance and development.
No argument from me there, especially as I have my own fork in github,
but that's up to the current maintainers.
Yup, I am thinking
(2012/09/22 11:01), sakamoto wrote:
(2012/09/22 10:02), Christopher Browne wrote:
If the present project is having a tough time doing enhancements, I
should think it mighty questionable to try to draw it into core, that
presses it towards a group of already very busy developers.
On the
2012/9/22 Satoshi Nagayasu sn...@uptime.jp:
(2012/09/22 11:01), sakamoto wrote:
(2012/09/22 10:02), Christopher Browne wrote:
If the present project is having a tough time doing enhancements, I
should think it mighty questionable to try to draw it into core, that
presses it towards a group
On Fri, Sep 21, 2012 at 9:45 AM, M.Sakamoto
sakamoto_masahiko...@lab.ntt.co.jp wrote:
Hi,
I'm sakamoto, maintainer of reorg.
What could be also great is to move the project directly into github to
facilitate its maintenance and development.
No argument from me there, especially as I have my
Andres those involved in the 9.3 Command triggers:
You may want to consider changing the command TRIGGER into a command
FILTER and possibly post processing TRIGGER that
is determined to be called INSIDE the FILTER. Or some way to pass
information between the FILTER and the post processing
Hi all,
Attached is the .txt and .pdf (both are imo readable and contain the same
content) with design documentation about the proposed feature.
Christan Kruse, Marko Tiikkaja and Hannu Krosing read the document and told me
about my most egregious mistakes. Thanks!
I would appreciate some
On 09/20/2012 06:34 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 08/23/2012 07:39 AM, Magnus Hagander wrote:
It doesn't break, of course ,since it's protected by the unique index.
But aren't you at risk of getting the very error message you're trying
to avoid?
Yeah,
Andres, nice job on the writeup.
I think one aspect you are missing is that there must be some way for
the multi-masters to
re-stabilize their data sets and quantify any data loss. You cannot do
this without
some replication intelligence in each row of each table so that no
matter how
Andrew,
Below is the patch that I mentioned at pgOpen. I'm pretty sure my
silly github pull request got screwed up anyway, so probably best to
ignore it. Regardless, please let me know what you think. I'd be
happy to rework it to operate off of a single hash, though I think
that
On 3 September 2012 15:20, Bruce Momjian br...@momjian.us wrote:
I spent the month of August going through 1.7k emails I had saved from
the previous year that required my attention. I want to thank everyone
for helping me close many open items, and for tolerating my questions.
Ideally I
A while back, I posted a pathological minimal-case query where, in order
to select one row from a users table, Postgres needed to scan the whole
users table, because the restriction was not visible to the GROUP BY.
At the time, Tom wrote:
Don't hold your breath waiting for that to change.
Boszormenyi Zoltan z...@cybertec.at writes:
new version with a lot more cleanup is attached.
I looked at this patch, and frankly I'm rather dismayed. It's a mess.
To start at the bottom level, the changes to PGSemaphoreLock broke it,
and seem probably unnecessary anyway. As coded, calling the
On 18 September 2012 14:23, Amit kapila amit.kap...@huawei.com wrote:
Please find the review of the patch.
Thanks for the review. Attached is an updated patch, and I've include
some responses to specific review comments below.
Extra test cases that can be added to regression suite are as
2012/9/22 Tatsuo Ishii is...@postgresql.org:
Tom, Kaigai,
Kohei KaiGai kai...@kaigai.gr.jp writes:
Tom, could you give us a suggestion which manner is better approach; whether
the PQfn should have responsibility for endian translation of
64bit-integer, or
callers (lo_tell64 or lo_seek64)?
Andrew Dunstan and...@dunslane.net writes:
The enum piece is now committed.
BTW, looking at that a second time ... the other CREATE IF NOT EXISTS
options we have issue a NOTICE when skipping the CREATE action. Is
there a reason this shouldn't do the same?
regards, tom
On 09/22/2012 05:39 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The enum piece is now committed.
BTW, looking at that a second time ... the other CREATE IF NOT EXISTS
options we have issue a NOTICE when skipping the CREATE action. Is
there a reason this shouldn't do the
On 09/22/2012 11:49 PM, Andrew Dunstan wrote:
On 09/22/2012 05:39 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The enum piece is now committed.
BTW, looking at that a second time ... the other CREATE IF NOT EXISTS
options we have issue a NOTICE when skipping the CREATE
Andrew Dunstan and...@dunslane.net writes:
On 09/22/2012 05:39 PM, Tom Lane wrote:
BTW, looking at that a second time ... the other CREATE IF NOT EXISTS
options we have issue a NOTICE when skipping the CREATE action. Is
there a reason this shouldn't do the same?
I'll add it.
I'm on it
Hannu Krosing ha...@2ndquadrant.com writes:
On 09/22/2012 11:49 PM, Andrew Dunstan wrote:
Not really, I guess we should for the sake of consistency, although TBH
I find it just useless noise and rather wish we hadn't started the
trend when we did the first DROP IF NOT EXISTS stuff.
Time for
I wrote:
... It strikes me though that if
we're going to invent an opt_if_not_exists production in the grammar,
there are a lot of other places where it should be used too, for
consistency if nothing else.
BTW, I tried to do this and realized that it doesn't work, because IF
is not a
On 09/22/2012 07:05 PM, Tom Lane wrote:
I wrote:
... It strikes me though that if
we're going to invent an opt_if_not_exists production in the grammar,
there are a lot of other places where it should be used too, for
consistency if nothing else.
BTW, I tried to do this and realized that it
On Sat, 2012-09-22 at 16:25 +0900, Satoshi Nagayasu wrote:
I think it's time to consider some *umbrella project* for maintaining
several small projects outside the core.
Well, that was pgfoundry, and it didn't work out.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Hi All,
I'm currently using PQexecParams() as part of a bridge to allow Postgres to be
used in another programming language. Not specifying the OIDs simplifies things
(for the end user), but bytea params still cause headaches, since they need to
be formatted differently and I receive the data
On Sat, Sep 22, 2012 at 7:45 PM, Peter Eisentraut pete...@gmx.net wrote:
On Sat, 2012-09-22 at 16:25 +0900, Satoshi Nagayasu wrote:
I think it's time to consider some *umbrella project* for maintaining
several small projects outside the core.
Well, that was pgfoundry, and it didn't work out.
On 09/20/12 16:34, Tom Lane wrote:
John Lumby johnlu...@hotmail.com writes:
On Fri, 22 Jun 2012 09:55:13, Robert Haas wrote:
I do notice that the RETURNING clause of the INSERT can't reference
NEW, which seems like a restriction that we probably ought to lift,
but it doesn't seem to have much
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I think it's time to consider some *umbrella project* for maintaining
several small projects outside the core.
Well, that was pgfoundry, and it didn't work out.
I'm not sure that is quite analogous to what was being proposed.
I read it as
2012/9/22 Tatsuo Ishii is...@postgresql.org:
Tom, Kaigai,
Kohei KaiGai kai...@kaigai.gr.jp writes:
Tom, could you give us a suggestion which manner is better approach;
whether
the PQfn should have responsibility for endian translation of
64bit-integer, or
callers (lo_tell64 or
On 09/21/2012 10:54:05 AM, Karl O. Pinc wrote:
On 09/20/2012 12:24:49 PM, Karl O. Pinc wrote:
I've had problems using pg_restore --data-only when
restoring individual schemas (which contain data which
has had bad things done to it). --clean does not work
well because of dependent
Whoops. Do over. Sent the wrong file.
On 09/23/2012 12:19:07 AM, Karl O. Pinc wrote:
On 09/21/2012 10:54:05 AM, Karl O. Pinc wrote:
On 09/20/2012 12:24:49 PM, Karl O. Pinc wrote:
I've had problems using pg_restore --data-only when
restoring individual schemas (which contain data
32 matches
Mail list logo
