(2010/01/04 13:18), Tom Lane wrote:
Robert Haas writes:
2010/1/3 KaiGai Kohei:
�if (number_of_attribute_origin(myrelid, oldattname)> 1)
� � �ereport(ERROR, ...);
Am I missing something?
That sounds about right to me,
It looks remarkably inefficient to me. Do you propose to search the
e
On Sun, Jan 3, 2010 at 10:39 PM, Robert Haas wrote:
>>
>> in syscache.c
>
> Hmm, I see this needs to be rebased over Tom's latest changes, but the
> conflict I got was in syscache.h, rather than syscache.c. Not sure if
> that's what you were going for or if there's another issue. Updated
> patch
> --- 49,63
>*
>*/
>
> ! #define Natts_pg_tablespace 6
Should be 5?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql
Robert Haas writes:
> 2010/1/3 KaiGai Kohei :
>> if (number_of_attribute_origin(myrelid, oldattname) > 1)
>> ereport(ERROR, ...);
>>
>> Am I missing something?
> That sounds about right to me,
It looks remarkably inefficient to me. Do you propose to search the
entire database's inheritan
Robert Haas writes:
> On Sun, Jan 3, 2010 at 10:17 PM, Takahiro Itagaki
> wrote:
>> Robert Haas wrote:
>>> - There are needless whitespace changes in the definition of struct
>>> Counters. The changes to the existing four members should be
>>> reverted, and the new members should be made to mat
2010/1/3 KaiGai Kohei :
> (2010/01/04 4:06), Robert Haas wrote:
>> On Jan 3, 2010, at 12:31 PM, Tom Lane wrote:
>>> In practice the reasonable engineering alternatives may just be to do
>>> what KaiGai's patch does, or to do nothing. In that case I think a good
>>> argument can be made for the lat
On Sun, Jan 3, 2010 at 9:10 PM, Takahiro Itagaki
wrote:
>
> Robert Haas wrote:
>
>> > If we want to keep backward compatibility, the issue can be fixed
>> > by adding pg_verifymbstr() to the function.
>>
>> I don't feel good about changing the return type of an existing
>> function, so I guess +1
On Sun, Jan 3, 2010 at 11:00 AM, Andrew Dunstan wrote:
> Hitoshi Harada wrote:
>> 2010/1/3 Andrew Dunstan :
>>> Hitoshi Harada wrote:
A question: Isn't there no possibility that we have our own
implementation to handle JSON (i.e. no use of external libraries)?
>>> Why should we reinvent
On Jan 3, 2010, at 4:18 PM, Hitoshi Harada wrote:
> That sounds good and seems possible, as far as operator returns JSON
> always. Perhaps every JSON fetching returns JSON even if the result
> would be a number. You can cast it.
>
> % SELECT ('{"foo":{"bar":["a","b","c"]}}' -> '["foo"][1]')::te
On Sun, Jan 3, 2010 at 10:17 PM, Takahiro Itagaki
wrote:
> Robert Haas wrote:
>
>> I have reviewed this patch and I think it looks pretty good. A couple
>> of minor nits:
>>
>> - There are needless whitespace changes in the definition of struct
>> Counters. The changes to the existing four memb
Bruce,
Sorry for not having replied sooner...
On Sun, Jan 3, 2010 at 5:43 PM, Bruce Momjian wrote:
>> 1) Right now pg_migrator preserves relfilenodes for TOAST files because
>> this is required for proper migration. Now that we have shown that
>> strategically-placed global variables with a se
Robert Haas wrote:
> I have reviewed this patch and I think it looks pretty good. A couple
> of minor nits:
>
> - There are needless whitespace changes in the definition of struct
> Counters. The changes to the existing four members should be
> reverted, and the new members should be made to
I wrote:
> Actually, in the problematic cases, it's interesting to consider the
> following strategy: when scalarineqsel notices that it's being asked for
> a range estimate that's outside the current histogram bounds, first try
> to obtain the actual current max() or min() of the column value ---
Robert Haas wrote:
> So, what is the roadmap for getting this done? It seems like to get
> rid of VFI completely, we would need to implement something like what
> Tom described here:
>
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg00249.php
>
> I'm not sure whether the current pat
Robert Haas wrote:
> > If we want to keep backward compatibility, the issue can be fixed
> > by adding pg_verifymbstr() to the function.
>
> I don't feel good about changing the return type of an existing
> function, so I guess +1 from me on the approach quoted above.
Ok, I just added pg_verif
Robert Haas wrote:
> > The attached patch verifies variable names at definition.
> > $ pgbench -D var:name=value
> > (global): invalid variable name 'var:name'
>
> I have reviewed this patch. I think that the basic idea of rejecting
> invalid variable names is probably a good one, but
Hitoshi Harada wrote:
2010/1/4 David E. Wheeler :
On Jan 3, 2010, at 11:40 AM, Andrew Dunstan wrote:
We allow composites as fields. The biggest mismatch in the type model is
probably w.r.t arrays. JSON arrays can be heterogenous and non-rectangular,
AIUI.
Cool, that sounds
2010/1/4 David E. Wheeler :
> On Jan 3, 2010, at 11:40 AM, Andrew Dunstan wrote:
>
>> We allow composites as fields. The biggest mismatch in the type model is
>> probably w.r.t arrays. JSON arrays can be heterogenous and non-rectangular,
>> AIUI.
>
> Cool, that sounds right.
Does it mean you sho
(2010/01/04 4:06), Robert Haas wrote:
> On Jan 3, 2010, at 12:31 PM, Tom Lane wrote:
>> In practice the reasonable engineering alternatives may just be to do
>> what KaiGai's patch does, or to do nothing. In that case I think a good
>> argument can be made for the latter. Nobody has ever complaine
On Mon, Dec 28, 2009 at 2:52 AM, Robert Haas wrote:
>
> Hearing no thoughts, I have implemented as per the above. PFA the
> latest version. Any reviews, comments, feedback, etc. much
> appreciated.
>
btw, you need to change
STATRELATT,
for
STATRELATTINH,
in syscache.c
--
Atentamen
Tom Lane wrote:
Andrew Dunstan writes:
andrew=# select 'a' || invalid_utf_seq() || 'b';
ERROR: invalid byte sequence for encoding "UTF8": 0xd0
HINT: This error can also happen if the byte sequence does not
match the encoding expected by the server, which is controlled by
Bruce Momjian wrote:
> pg_migrator has become more popular recently, so it seems time to look
> at some enhancements that would improve pg_migrator. None of these are
> required, but rather changes that would be nice to have:
>
> 1) Right now pg_migrator preserves relfilenodes for TOAST files be
Peter Eisentraut writes:
> This was a random attempt to figure something out about min/max on row
> types:
> => select min(a) from (values (row(1,2,3)), (row(3,4,5))) as x(a);
> ERROR: 42809: record type has not been registered
> LOCATION: lookup_rowtype_tupdesc_internal, typcache.c:341
> I do
This was a random attempt to figure something out about min/max on row
types:
=> select min(a) from (values (row(1,2,3)), (row(3,4,5))) as x(a);
ERROR: 42809: record type has not been registered
LOCATION: lookup_rowtype_tupdesc_internal, typcache.c:341
I don't know whether it's supposed to work
Andrew Dunstan writes:
> There are two issues with this patch. First, how far if at all should it
> be backpatched? All the way, or 8.3, where we tightened the encoding
> rules, or not at all?
Forgot to mention --- I'm not in favor of backpatching. First because
tightening encoding verificatio
Andrew Dunstan writes:
> andrew=# select 'a' || invalid_utf_seq() || 'b';
> ERROR: invalid byte sequence for encoding "UTF8": 0xd0
> HINT: This error can also happen if the byte sequence does not
> match the encoding expected by the server, which is controlled by
> "client_en
David E. Wheeler wrote:
Second, It produces errors like this:
andrew=# select 'a' || invalid_utf_seq() || 'b';
ERROR: invalid byte sequence for encoding "UTF8": 0xd0
HINT: This error can also happen if the byte sequence does not
match the encoding expected by the server, which is con
On Jan 3, 2010, at 11:54 AM, Andrew Dunstan wrote:
> There are two issues with this patch. First, how far if at all should it be
> backpatched? All the way, or 8.3, where we tightened the encoding rules, or
> not at all?
8.3 seems reasonable.
> Second, It produces errors like this:
>
> andr
On Jan 3, 2010, at 11:40 AM, Andrew Dunstan wrote:
> We allow composites as fields. The biggest mismatch in the type model is
> probably w.r.t arrays. JSON arrays can be heterogenous and non-rectangular,
> AIUI.
Cool, that sounds right.
> OK, but hstores are flat, unlike JSON. We need some way
I wrote:
I think the attached patch plugs the direct SPI holes as well.
There are two issues with this patch. First, how far if at all should it
be backpatched? All the way, or 8.3, where we tightened the encoding
rules, or not at all?
Second, It produces errors like this:
andrew=# s
David E. Wheeler wrote:
On Jan 3, 2010, at 8:00 AM, Andrew Dunstan wrote:
I think the minimal functionality I'd want is:
convert record to JSON
convert JSON to record
With caveats as to dealing with nested structures (can a record be an attribute
of a record?).
We allow
On Sun, Jan 3, 2010 at 17:45, Peter Eisentraut wrote:
> On fre, 2010-01-01 at 20:25 +0100, Magnus Hagander wrote:
>> The win64 port has showed that we have two sockets declared
>> incorrectly. They are supposed to be declared as SOCKET on win32, but
>> they are declared as int. See attached patch.
On Jan 3, 2010, at 12:31 PM, Tom Lane wrote:
In practice the reasonable engineering alternatives may just be to do
what KaiGai's patch does, or to do nothing. In that case I think a
good
argument can be made for the latter. Nobody has ever complained about
this from the field AFAIR; but we
On Jan 1, 2010, at 6:01 PM, Kevin Grittner wrote:
> It's very soon going to be critical that I be able to test particular
> interleavings of statements in particular concurrent transaction sets
> to be able to make meaningful progress on the serializable
> transaction work. It would be wonderful
On Jan 3, 2010, at 8:00 AM, Andrew Dunstan wrote:
> I think the minimal functionality I'd want is:
>
> convert record to JSON
> convert JSON to record
With caveats as to dealing with nested structures (can a record be an attribute
of a record?).
> extract a value, or set of values, from
Tom Lane wrote:
Andrew Dunstan writes:
One thing that I am pondering is: how does SPI handle things if the
client encoding and server encoding are not the same?
What? client_encoding is not used anywhere within the backend.
Everything should be server_encoding.
Robert Haas writes:
> Upthread you appeared to be endorsing what KaiGai has implemented here:
> http://archives.postgresql.org/pgsql-hackers/2009-11/msg00147.php
No, I said that forbidding conflicting renames would be a good solution.
I did not endorse any specific means of testing for such a con
Andrew Dunstan writes:
> One thing that I am pondering is: how does SPI handle things if the
> client encoding and server encoding are not the same?
What? client_encoding is not used anywhere within the backend.
Everything should be server_encoding.
regards, tom lane
-
Jeff Davis wrote:
> I started a wiki page here:
>
> http://wiki.postgresql.org/wiki/Serializable
I've filled it in with all relevant information which came to mind.
If you can spot something I missed, please feel free to correct that
or let me know so that I can.
-Kevin
--
Sent via pgsql
On fre, 2010-01-01 at 20:25 +0100, Magnus Hagander wrote:
> The win64 port has showed that we have two sockets declared
> incorrectly. They are supposed to be declared as SOCKET on win32, but
> they are declared as int. See attached patch.
>
> Given that SOCKET is actually defined as int on win32
Hitoshi Harada wrote:
2010/1/3 Andrew Dunstan :
Hitoshi Harada wrote:
A question: Isn't there no possibility that we have our own
implementation to handle JSON (i.e. no use of external libraries)?
Why should we reinvent a wheel someone else has already invented? This is
wha
On Fri, Jan 1, 2010 at 1:39 PM, Simon Riggs wrote:
>> Interesting. It's not obvious to me how killing an *idle* session can
>> resolve a deadlock. AIUI a deadlock requires a cycle in the waits-for
>> graph, and an idle transaction is not waiting for a lock acquisition.
>
> In strict theory, yes.
>
On Sat, Jan 2, 2010 at 7:47 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote:
>>> As for the overhead, these queries are not zero-maintenance. I still
>>> think that the usefulness of tab completion here is pretty darn
>>> minimal,
>>> since mos
On Sat, Jan 2, 2010 at 2:32 PM, Tom Lane wrote:
> KaiGai Kohei writes:
>> (2009/12/30 10:38), Robert Haas wrote:
>>> No longer applies. Can you rebase?
>
>> The attached patch is the rebased revision.
>
> I'm not really impressed with this patch, because it will reject
> perfectly legitimate mul
Andrew Dunstan wrote:
Andrew Dunstan wrote:
I think the plperl glue code should check returned strings using
pg_verifymbstr().
Please test this patch. I think we'd probably want to trap the
encoding error and issue a customised error message, but this plugs
all the holes I can see w
> I tried this but didn't have any luck crashing the backend. libpq gets
> tremendously confused by the extra ReadyForQuery responses, which is
> unsurprising. The postmaster log shows
>
> LOG: could not send data to client: Broken pipe
> ERROR: relation "foo" does not exist at character 15
>
On Fri, Jan 01, 2010 at 03:31:58PM -0500, Kris Jurka wrote:
> The JDBC driver does want "cancel if active" behavior. The JDBC API
> specifies Statement.cancel() where Statement is running one particular
> backend query. So it really does want to cancel just that one query.
> Already this is
On Sat, Jan 02, 2010 at 08:21:35PM -0500, Tom Lane wrote:
> 3. Inefficient. It seems likely to me that filtering on the prefix on
> the backend side isn't going to be more efficient than doing it on the
> client side, except maybe in the schema-name cases. If the conditions
> were phrased in a wa
48 matches
Mail list logo
