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 contai
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 depend
> 2012/9/22 Tatsuo Ishii :
>> Tom, Kaigai,
>>
>>> Kohei KaiGai 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)?
>>>
>>> A
-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
On 09/20/12 16:34, Tom Lane wrote:
John Lumby 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 to do with your patch.
On Sat, Sep 22, 2012 at 7:45 PM, Peter Eisentraut 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.
There se
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 a
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)
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 do
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 rese
Hannu Krosing 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 a GUC
> exist
Andrew Dunstan 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 already.
On 09/22/2012 11:49 PM, Andrew Dunstan wrote:
On 09/22/2012 05:39 PM, Tom Lane wrote:
Andrew Dunstan 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 reaso
On 09/22/2012 05:39 PM, Tom Lane wrote:
Andrew Dunstan 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?
Andrew Dunstan 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 lane
--
Sent via
2012/9/22 Tatsuo Ishii :
> Tom, Kaigai,
>
>> Kohei KaiGai 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)?
>>
>> Adding anything in
On 18 September 2012 14:23, Amit kapila 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 below:
>
> 1. where cla
Boszormenyi Zoltan 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 "condition
chec
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. T
On 3 September 2012 15:20, Bruce Momjian 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 would have dealt
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 would
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 disastr
On 09/20/2012 06:34 PM, Tom Lane wrote:
Andrew Dunstan 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, looking further this was
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 feed
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 tr
On Fri, Sep 21, 2012 at 9:45 AM, M.Sakamoto
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 own fork in github,
>>but
2012/9/22 Satoshi Nagayasu :
> (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
(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.
>>
28 matches
Mail list logo
