it?
=# \x
=# SELECT '["A"]'::json,
array_to_json(ARRAY['A']),
array_to_json(ARRAY['"A"'::json]);
-[ RECORD 1 ]-+--
json | ["A"]
array_to_json | ["A"]
array_to_json | ["\"A\"&quo
iles. Is it an
intended behavior? I think they are harmless, so we don't have
to change the codes; "include" might be useful even in recovery.conf,
and "custom_variable_classes" will be "unrecognized recovery
parameter" error after all.
--
Itagaki Takahi
s you say, the recovery will just error out. You have to
> clean your recovery.conf file then try again (I just tried and confirm).
>
> I personally don't see any harm to have the features in all currently
> known uses-cases, and I don't see any point in walking an extra mile
>
I attached my past works. It would be a bad
design as discussed above, but it would be a help to see in which
case the approach doesn't work.
--
Itagaki Takahiro
format_with_to_char-20101125.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> createNewConnection().
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
lso handles virtual tuples.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
mmented out
at the end of pgxml_xpath(), but is it enough to enable the code?
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
SING for non-btree PRIMARY KEY/UNIQUE indexes.
Ideas and suggestions?
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
y, SJIS
is still used widely, but it is not a valid server encoding.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ings are never
truncated. I'm not sure why connection strings are logged in your log.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
replace(
convert_from(
pg_read_binary_file('path', 0, -1),
'encoding'),
'key1', 'value1', 'key2', 'value2')
);
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ng to server_encoding),
it still won't work well when error messages are raised. The client
expects the original client encoding, but messages are sent in the
file encoding. It would be a security hole.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
RIGGER trg INSTEAD OF [tab]
(no candidates)
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
;< N) = t.tgtype".
Patch attached. If you think my changes are ok,
please change the patch status to "Ready for Committer".
--
Itagaki Takahiro
psql_view_trigger_tab_completion_6.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
cause
SERVER is always the local file system and USER is always the OS's user
who started the postmaster. I'm not sure how we should treat cases
where those settings don't have any configurations.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On Tue, Nov 30, 2010 at 18:47, Dimitri Fontaine wrote:
> Itagaki Takahiro writes:
>> There are no discussion yet for 1, but I think we need some restrictions
>
> Well, as a first level of restrictions, the function is superuser
> only. I understand and share your concerns, b
We will need only one doc for them.
Note that if we call replace() with 3 args, the non-VARIADIC version
is called. So, there is no performance penalty.
* We might rename pg_convert_and_execute_sql_file() to
pg_execute_sql_file_with_encoding() or so to have the same prefix.
/backend/utils/adt/oracle_compat.c(7): * Author: Edmund Mergl
src/backend/utils/adt/txid.c(14): * Author: Jan Wieck, Afilias USA
INC.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
te credit in the
> commit message so if we want history it's there
Hi, folks. Thanks for all of your replies.
Dimitri, your name cannot be added in source files,
but will be recorded in commit logs ;-)
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
aybe your proposed
> name fits better in PostgreSQL. I'd leave it for commiter :)
Agreed. I also prefer pg_read_file_all rather than pg_read_whole_file :P
--
Itagaki Takahiro
pg_execute_from_file.v9.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
sed at SQL level?
Yes, because the non VARIADIC version is much faster than the
VARIADIC one. Of course we could optimize the performance of
replace_text_variadic(), but I think VARIADIC argument itself
is slow because it puts arguments into an array shape.
--
Itagaki Takahiro
--
Se
though details of the implementation should be kept in copy.c.
How about splitting the file_fdw patch into two pieces?
One exports the copy functions from the core, and another
implements file_fdw using the infrastructure.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list
I have no objections to hide some of the subroutines if there are
any problems.
| $sql := replace(
| convert_from(
|pg_read_binary_file($path, 0),
|$encoding),
| '@extschema@', $schema));
| EXECUTE $sql;
--
Itagaki Takahiro
--
Sent via pgsql-hackers
,
* I still think an explicit passing collations from-function-to-function
is horrible because we might forget it in some places, and almost existing
third party module won't work. Is it possible to make it a global variable,
and push/pop the state when changed? Sorry I'm missing somethi
| setting
-+-
lc_collate | C
lc_ctype| C
server_encoding | UTF8
(3 rows)
postgres=# SELECT * FROM pg_class WHERE relname ILIKE 'pg%';
ERROR: no collation was derived
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (p
On Sat, Dec 11, 2010 at 05:30, Andrew Dunstan wrote:
> On 12/04/2010 11:11 PM, Itagaki Takahiro wrote:
>> One exports the copy functions from the core, and another
>> implements file_fdw using the infrastructure.
>
> Who is actually going to do this split?
I'm working f
file.
i.e, (path, offset, size) and (path). Two args version (path, offset)
doesn't seem to be so useful. In addition, CREATE EXTENSION will always
call it with offset=0, no?
- We don't need some of added #include "utils/array.h" anymore.
--
Itagaki Takahiro
--
Sent
read files in multi-byte encoding because
1. The encoding must be same with the server encoding.
2. Users need to specify correct offset in the file
not to split multi-byte characters.
So, it'd be better to improve pg_read_file() aside from EXTENSION anyway.
I think pg_read_whole_binary_fil
On Tue, Dec 14, 2010 at 12:02, Robert Haas wrote:
> On Mon, Dec 13, 2010 at 9:41 PM, Itagaki Takahiro
>> So, the most important part of this patch is allowing to read any
>> files in the server file system. The current pg_read_file() allows
>> to read only files under $PGDA
read_file() is also superuser-only, no?
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ally kept in a holder of the CopyState.
- You need to pass non-NULL filename. If it is NULL, the server
tries to read data from the client.
- The framework supports to read dumped binary files and files
with OIDs. If you don't want to support them, please check
parameters not to inclu
Do you suggest to define a wrapper view if we want to create an updatable
foreign table? I think users don't like such kind of wrappers.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
lt-in update feature?
There are no definitions in the SQL standard about interface for updates.
So, I think RULE and TRIGGER are the best solution for now.
In addition, even if we support some kinds of built-in update feature,
I still think RULE and TRIGGER are useful, for example, logging purpose.
ile with encoding, i.e., 1 and 2.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"utils/genfile.h". No DirectFunctionCall'ing, we can easily
> remove SQL callable forms.
>
> So what we need is 2, 3 and 4 (because 4 builds on 2).
No, 3 is not needed. You can use SPI_exec() directly instead of
exporting execute_sql_string().
--
Itagaki Takahiro
--
S
ql = replace(
convert_from(pg_read_binary_file($path), $encoding),
'@extschema@', $schema);
SPI_exec(TextDatumGetCString(sql));
I think it is a more flexible solution than adding 'encoding'
parameter to pg_read_file().
--
Itagaki Takahiro
--
Sent via
'd like to add #1 at the same time if required.
Or, if we're planning not to use pg_read_file functions in the
EXTENSION patch, we don't need #2 anyway.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
erence is 'offset' argument is removed from 'whole' mode.
So, we'll have (path, offset, length) and (path) versions.
Checking with convert_and_check_filename is left as-is.
--
Itagaki Takahiro
pg_read_binary_file.patch
Description: Binary data
--
Sent via pgsql-hackers m
elation. TupleDesc might be enough for the purpose, but I've not
changed the type because of DEFAULT columns.
OTOH, CopyFrom(cstate, rel) will require an additional 'rel' argument,
that means the "target" to be inserted, though it's always same with
the above &q
de.
It's also true in the service control on MS Windows.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
iewers delete their names?
I tested it in program-level, but the code-level review is still needed.
I'm worried about whether "no holes" checks are required in COLLATE
hand-off from function to function. If so, the review will be a harder
work than the case where the framework guarante
| Modifiers | Storage | Description
+-+---+-+-
i | integer | | plain |
j | integer | default 5 | plain |
Has OIDs: no
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
eral array:
IN ARRAY ARRAY[1, 3, 5]
Are there any improvement for the issue?
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
for COPY FROM and COPY TO later. So, it might be better to export
them as "FileReader API" or some similar names rather than CopyFrom.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
xpanded auto.
How about adding not only "auto" but also "on" and "off" as arguments
for \x? If not specified, the default behavior will be still "toggle".
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
ld
have used only installed files because they are used in "make *installcheck*".
*** a/contrib/XXX/sql/XXX.sql
***
SET client_min_messages = warning;
! \set ECHO none
! \i XXX.sql
! \set ECHO all
RESET client_min_messages;
--- 7,13
SET client_min_messages = warning;
! CREATE E
riter" APIs, like:
cstate = BeginCopyTO(...);
while (tuple = ReadTupleFromSomewhere()) {
/* write the tuple into a TSV/CSV file */
NextCopyTo(cstate, tuple);
}
EndCopyTo(cstate);
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
IMO.
>
> Oh, I wasn't aware that Itagaki-san had objected to Tom's proposal.
I agree that "the default encoding is UTF-8", but it should be
configurable by the 'encoding' parameter in control files.
If we use UTF-8 as the the default encoding, we need to treat
3 encodi
n initialize modules one-by-one
and be called on demand, for example, at SHOW, searching pg_settings,
or assignment to variables with unknown classes.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Dec 20, 2010 at 01:34, Tom Lane wrote:
>> I agree that "the default encoding is UTF-8", but it should be
>> configurable by the 'encoding' parameter in control files.
>
> Why is it necessary to have such a parameter at all?
UTF-8 is not a superset o
irely.
I think so. It would be better to remove the CVC support and related code.
Preloading modules that defines CVC is a good direction to fix the issue,
but we need more consideration about where to do it.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
ulate EUDC text. It will be written
in EUC_JP because SHIFT_JIS is not supported in postgres. Also, it
cannot be rewritten in UTF-8 because there are no mapping for the
characters used in it.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
uld be
we don't need (void *) when we cast a pointer to void *, but need
(Type *) when we cast a void pointer to another type.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Dec 21, 2010 at 21:32, Itagaki Takahiro
wrote:
> On Tue, Dec 21, 2010 at 20:14, Shigeru HANADA
> wrote:
>> Attached is the revised version of file_fdw patch. This patch is
>> based on Itagaki-san's copy_export-20101220.diff patch.
>
> #1. Don't you h
reign tables.
Almost all of the foreign tables should have different data format
from HeapTuple, including pgsql_fdw.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ar * ?
> But that breaks our guideline about assembling
> translatable strings from small pieces. Maybe it'd be OK if the piece
> is just a fragment of SQL syntax, though - not sure.
Agreed. should be a SQL syntax,
so we won't have to translate the part.
--
Itagaki Takahi
solve
+ shift/reduce errors without OF. To solve the errors, we might need
+ to make OF, MEMBER, and/or SUBMULTISET to reserved keywords. They
+ are reserved keywords in the SQL standard.
+ */
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
e an option to apply those constraints at SELECT.
We can find corrupted foreign data at that time.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> specific fields.
+1 for the separate view. "backend_start" (or replication_start?)
might be also reasonable.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
_port,
S.backend_start,
S.xlog_sending
FROM pg_stat_get_walsender(NULL) AS S, pg_authid U
WHERE S.usesysid = U.oid;
--
Itagaki Takahiro
get_host_and_port-20110104.patch
Description: Binary data
pg_stat_walsender-20110104.patch
Description: Binary data
--
Sent via pgsql
quot;max_wal_senders" GUC parameter. So, users still
need to know what "wal_senders" is.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
9.1, we would be better to use
ExecStoreVirtualTuple() in file_fdw and pgsql_fdw for future optimization.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
fo for monitoring and patch testing.
What will we name xlog locations that have been received? We call
xlog locations sent to standby as "sentPtr". If we have sync rep,
we will have two locations for each wal sender. For example,
we can call them "sent_location" and
ender/receiver as their names because standby
activity in slaves could contain not only a wal receiver but also a
recovery process.
--
Itagaki Takahiro
pg_stat_replication-20110107.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
to update SGML for the view. I'll do it soon.
Thanks for the heads-up.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jan 7, 2011 at 21:49, Magnus Hagander wrote:
>> New system view pg_stat_replication displays activity of wal sender
>> processes.
>
> Umm. SGML updates?
Oops, sorry. Additional documentation patch attached.
Could you proofread the text?
--
On Sat, Jan 8, 2011 at 01:09, Robert Haas wrote:
>> Oops, sorry. Additional documentation patch attached.
>> Could you proofread the text?
>
> Done, edited, committed, along with the catversion bump (as noted by Tom).
Thanks a lot!
--
Itagaki Takahiro
--
Sent via pgsql-ha
tency.
-- Forwarded message --
From: Itagaki Takahiro
Date: Fri, Jan 7, 2011 at 16:34
Subject: Re: [TESTERS] [TEST REPORT] 9.1Alpha3 Feature E.1.4.7.2 in
release notes.
To: Ramanujam
Cc: pgsql-test...@postgresql.org
On Fri, Jan 7, 2011 at 15:54, Ramanujam wrote:
> [Release]: 9.1Alpha3.
On Tue, Jan 11, 2011 at 11:10, Tom Lane wrote:
> Itagaki Takahiro writes:
>> It was reported from a tester that we don't have casts of money from/to
>> integer
>> types even though we have from/to numeric type.
>
> In most locales, the idea isn't sensible
hem with
MULTISET arguments.
One exception might be collect() aggregate function because
we might need to change the result type from array to multiset.
collect(anyelement) => anyarray for now
Note that fusion() won't be an issue because we can overload it:
fusion(anyarray) =>
they are protections only for them.
=# SELECT A.stavalues1 SUBMULTISET OF B.stavalues1
FROM pg_statistic A, pg_statistic B
WHERE A.stakind1 = 2 AND B.stakind1 = 2;
ERROR: cannot compare incompatible arrays
DETAIL: Arrays with element types name and oid[] are not compatible
for comparison.
--
I
ase don't break up the string in errdetail() even if it's longer than
> 80 chars. (The function below this one has this too)
OK, I'll fix them,
but the broken up messages come from the existing code.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t;switchover"
operations. "pg_ctl promote" might be more neutral, but users might be
hard to imagine replication feature from "promote".
- pg_ctl should unlink failover_files when it failed to send failover signals.
- "standby_triggered" variable might be re
n recommend to use UTF-8 + C locale combinations
for users, but I'm not sure it's the most common use-cases or not.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s the hook.
file_fdw likes #1 because there are no external storage to store
statistics for CSV files, but pgsql_fdw might prefer #2 because
the remote server already has stats for the underlying table.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
ATE FOREIGN TABLE arr_text (
i integer OPTION (column 1), -- column position in csv file
t text[] OPTION (column 'all the rest'),
d dateOPTION (column 2)
) SERVER file_server
OPTIONS (format 'csv', filename '/path/to/ragged.csv');
--
Itagaki
re the contents.
Is it possible or not?
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(1 row)
postgres=# SELECT pg_advisory_unlock_all();
pg_advisory_unlock_all
----
(1 row)
postgres=# ROLLBACK;
ROLLBACK
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nd compare support functions.
So, I think there is no regression here as long as raw values and
toasted byte sequences have one-to-one correspondence.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
acuumlo-like special sweeping logic for the security label table.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
o
> superuser only seems perfectly reasonable and in line with the
> encouragement not to use the replication user for login.
>
> Objections?
It hides all fields in pg_stat_wal_senders(). Instead, can we just
revoke usage of the function and view? Or, do we have some plans
to add fields whic
as
> HeapTuple.
I think file_fdw can return tuples in virtual tuples forms,
and ForeignNext() calls ExecMaterializeSlot() to store tableoid.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
,
but there is still the same issue -- we might have different
compressed results if we use different algorithm for TOASTing.
So, it would be better to apply the present patch as-is.
We can improve the comparison logic over the patch in another
development cycle if possible.
--
Itagaki Taka
n about "nfiltered" parameter. The best
place would be around the descriptions of "loops" in "Using EXPLAIN" page:
http://developer.postgresql.org/pgdocs/postgres/using-explain.html
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-ha
plainInfo, that is a plan text, is not enough for complex
FdwPlans. However, since we don't have any better solution for now,
we could have the variable for 9.1. It's much better than nothing.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
we might not have to include JSON
in the core. We can download any JSON implementations from the
site after installing the core server. Of course, if we will
use JSON types in the core (EXPLAIN JSON output?), we have to
include one of them.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailin
is postmaster sets a flag in the shared memory area
>> indicating it rceived SIGTERM before forwarding the signal to
>> backends.
Is it enough for your purpose and do we think it is more robust way?
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
?
I tested the performance on my desktop PC, but I cannot see any
differences. But welcome if any of you could test on high-performance
servers.
Comparison with file_fdw would be more interesting
If they have similar performance, we could replace "COPY FROM" to
"CREATE TABLE AS
t an idea -- we could return complex node trees with explainInfo
if we use XML or JSON for the format. For example, pgsql_fdw can
return the result from "EXPLAIN (FORMAT json)" without modification.
It might be one of the reasons we should should support JSON in the core :)
--
tions? Another solution might be adding a dummy assignment
after calls of die_horribly().
--
Itagaki Takahiro
noreturn.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/
ile_fdw_validator HANDLER file_fdw_handler;
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
;see also" items.
* Docs need some tags for itemized elements or pre-formatted codes.
They looks itemized in the sgml files, but will be flattened in
complied HTML files.
* A declaration of assign_log_csv_fields() at the top of elog.c
needs "extern".
* There is a duplicated declar
now, but will return a multiset when we
support true multiset data type.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
|
(1 row)
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e the overhead, we should cache the conversion procedure
in CopyState. How about adding something like "FmgrInfo file_to_server_covv"
into it?
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
* [off topic] I found some installer scripts are inconsistent.
They uses CREATE FUNCTION for some of functions, but CREATE OR REPLACE
FUNCTION for others. We'd better write documentation about how to write
installer scripts because CREATE EXTENSION has some implicit assumptions
in them. For example, &
values, but t and f are not valid.
You should use true and false (or 't' and 'f') for the cases.
(So, your "INSERT INTO" example is broken.)
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Aug 31, 2010 at 8:04 PM, Itagaki Takahiro
wrote:
> * How to determine which method was used?
> We can get some information from trace_sort logs,
> but CLUSTER VERBOSE would be better to log
> which CLUSTER method was used.
I wrote a patch to improve CLUSTER VERBOSE (and
d be better in terms of performance.
For example, CREATE or ALTER REPLICATION.
Of course, function-based approach is more flexible and
less invasive to the SQL parser. There are trade-offs.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
ould that be the plan of your command proposal?
What I meant was function-based maintenance does not work well in some
cases. I heard before pg_start_backup( no-fast-checkpoint ) caused table
bloating problem because it was a long transaction for 20+ minutes.
The backup function would have the simi
1 - 100 of 891 matches
Mail list logo
