...

или внеочередные заметки



  • 1

GUCs influencing I/O routines

Hi Oleg,

Tom Lane has said at least a few times that he thinks that having the behavior of I/O functions influenced by a GUC is a bad idea (he has said this in relation to other patches at other times, but often enough that I've heard it a few times). Without commenting on the validity of that view, I ask that you reconsider this aspect of the the new patch, if only because it's likely to face resistance during review.

Would it not be acceptable to have different datatypes representing the user's choice to use curly or square brackets? If one type (say the square brackets type) is binary coercible to another type (say the curly brackets type), then ALTER TABLE ... SET DATA TYPE won't need to rewrite a table. It also won't be necessary for any indexes on these columns to be rebuilt in that scenario. The choice to change the type will be cheap.

I'm sure you know all of this already, but hopefully my suggestions are still helpful.

hstore operators doesn't work on 9.4 beta2

testdb=# select 'a=>1,b=>{c=>3,d=>{4,5,6}},1=>f'::hstore %> 'b'->'c';
ERROR: operator does not exist: hstore %> unknown
LINE 1: select 'a=>1,b=>{c=>3,d=>{4,5,6}},1=>f'::hstore %> 'b'->'c';
^
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.


testdb=# \dx
List of installed extensions
Name | Version | Schema | Description
---------+---------+------------+--------------------------------------------------
hstore | 1.3 | public | data type for storing sets of (key, value) pairs
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(2 rows)

testdb=# select version();
version
---------------------------------------------------------------------------------------------------------------
PostgreSQL 9.4beta2 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit
(1 row)

  • 1
?

Log in