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
gt; I know so dblink is "deprecated" interface - but it has necessary
>> functionality still - it support a writable statements.
So, "dblink on FDW connection" seems to be a possible solution.
We pass a query as a form of a plain text.
--
Itagaki Takahiro
--
Sent via p
uot;
> LINE 1: create extension pgtap-core;
>
> Parser error?
You need double-quotes around the name:
=# CREATE EXTENSION "uuid-ossp";
CREATE EXTENSION
--
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 manual configuration for now.
It would be reasonable if we had used automatic detection of
character encoding, but we don't. In addition, some crazy
encoding might use BOM codes as a valid character.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
, we might also support COPY TO WITH BOM for writes.
Comments welcome.
--
Itagaki Takahiro
copy_from_bom.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
te those README files as documentation, we could
move them into "internals" section in the SGML doc tree. If so,
the translated README will be a part of the doc translation project.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
urn only one value instead of 512.
Anyway, I'm not sure we need to include the query mode into the pgbench's
codes. Instead, how about providing "a sample script" as a separate sql
file? pgbench can execute any script files with -f option.
--
Itagaki Takahiro
--
Sent via pgsql-h
' is no longer necessary.
>
> The similar problem exists in dblink_get_result and dblink_record_internal.
> Attached patch fixes those problems.
--
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
h/without timeout in the cases, 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
s integer values of sub-META_COMMAND
instead of string comparison for each loop.
--
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
d page instead of the old pinned one.
Of course, copy-on-writing is more complex than skipping pinned pages,
but I wonder we cannot vacuum at all in some edge cases with the
skipping method.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
t; Guess it wouldn't hurt too much.
Yes, probably. AFAIK, RHEL 5 cannot readahead in backward scans.
It might be improved in the latest kernel, but it would be safe
not to rely on kernels except simple forward scans.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
preferred.
--
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 Thu, Mar 10, 2011 at 12:55, Robert Haas wrote:
> On Wed, Mar 9, 2011 at 8:33 PM, Itagaki Takahiro
> wrote:
>> I found trivial mistakes in the recently added files.
>> Will they fixed by some automated batches, or by manual?
> I think these should be fixed manua
th_delay.c.
- "IDENTIFICATION $PostgreSQL$" in pg_collation.h, syncrep.h, and syncrep.c
Other files has their actual paths in the same place.
--
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
Is it reasonable? Or, do we have alternative ways for the same purpose?
--
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
Here is a patch to support CREATE UNLOGGED TABLE in psql tab-completion.
It also fixes a bug that DROP is completed with TEMP and UNIQUE unexpectedly
and cleanup codes for DROP OWNED BY in drop_command_generator().
--
Itagaki Takahiro
psql_tab_completion_for_unlogged-20110223.patch
Description
On Tue, Feb 22, 2011 at 18:11, Cédric Villemain
wrote:
> 2011/2/22 Itagaki Takahiro :
>> psql \d(+) doesn't show any information about UNLOGGED and TEMP attributes
>> for the table. So, we cannot know the table is unlogged or not unless
>> we directly select from pg_clas
they are always created in pg_temp_N schema.
--
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
which RSS fields we
> want.
I think we need to overhaul validators in 9.2 listening to FDW developers'
opinions anyway. The text array is an example, but there should be many
other requirements. Personally, I'd like to have a method to list available
options from SQL. We should also consider
On Fri, Feb 18, 2011 at 20:12, Itagaki Takahiro
wrote:
> + extern char *pg_any_to_server(const char *s, int len, int encoding);
> + extern char *pg_server_to_any(const char *s, int len, int encoding);
I applied the version with additional codes for file_fdw.
--
Itagaki Takahiro
--
Se
| C | C |
--
Itagaki Takahiro
regression.diffs
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
uot;heap.c", Line: 1246)
=# CREATE UNLOGGED SEQUENCE us;
TRAP: FailedAssertion("!(relkind == 'r' || relkind == 't')", File:
"heap.c", Line: 1246)
The most easiest fix would be preventing them in parser level.
--
Itagaki Takahiro
--
Sent via p
On Fri, Feb 18, 2011 at 03:57, Robert Haas wrote:
> On Wed, Feb 16, 2011 at 10:45 PM, Itagaki Takahiro
> I am not qualified to fully review this patch because I'm not all that
> familiar with the encoding stuff, but it looks reasonably sensible on
> a quick read-through. I
On Fri, Feb 18, 2011 at 13:15, Shigeru HANADA wrote:
> When I've used COPY TO for testing file_fdw, I got wrong result.
> It would be because DR_copy's processed is not initialized in
> CreateCopyDestReceiver(). Please see attached patch.
Oops, thanks, applied.
--
Itagaki
On Thu, Feb 17, 2011 at 17:05, Itagaki Takahiro
wrote:
> I did a few cosmetic fixes, mainly lmgr/README and make a subroutine
> ReleaseLockForOwner() for LockReleaseSession and LockReleaseCurrentOwner.
Committed with a few typo fixes. Thanks, Marko!
--
Itagaki Takahiro
--
Sent via
he, in which cache search doesn't seem like overhead.
We need to research what we should cache for conversion procs.
We will need 4 bytes per conversion pair if we cache only OIDs,
but sizeof(FmgrInfo) bytes if we use the same way as ToXXXConvProc cache.
--
Itagaki Takahiro
--
Sent via pgs
;double quoted", but encoding names are not identifiers.
--
Itagaki Takahiro
copy_encoding-20110217.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
a virtual tuple. */ , right?
* #include is needed.
--
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
r the better.
Thanks comments. I've applied the COPY API patch.
--
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
astructure. The extension
will lack of file encoding support, but still useful for many cases.
--
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
pg_settings view, but there were no better
alternative solutions in the past discussion.
* csvlog_fields is marked as PGC_POSTMASTER. It can protect mixed formats
in a csv file on default log_filename, but other similar GUC variables
are usually marked AS PGC_SIGHUP.
--
Itagaki Takahiro
--
Sent vi
est run, but if anyone feels
>> that's justified, I can arrange something.
>
> Based on this, I've taken the liberty of marking the patch Ready for
> Committer.
Thank you very much for performance testing and reviewing!
The result is interesting because I didn't in
turn" should be removed.
*** 2139,2144 write_csvlog(ErrorData *edata)
--- 2379,2386
write_pipe_chunks(buf.data, buf.len, LOG_DESTINATION_CSVLOG);
pfree(buf.data);
+
+ return;
}
/*
--
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
codes using the same operation in other files?
> There's more, primairly lack of comments and what I consider poor
> function naming ("sort_or_unique()" ? really?),
Could you suggest better names?
--
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
ttle more, I'd raise two items:
* Should we print foreign table names in error messages?
http://archives.postgresql.org/pgsql-hackers/2011-02/msg00427.php
* COPY encoding patch was rejected, but using client_encoding is
logically wrong for file_fdw. We might need subset of the patch
for file_
om the patch; it will add only a few array
functions. Then, please let me know functions you don't want to include
in the core, if any. I'll remove them at the same 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
On Thu, Feb 10, 2011 at 19:37, Christoph Berg wrote:
> Currently, tab-completing :variable names in psql does not work at the
> beginning of the line. Fix this by moving the code block before the
> "empty buffer" case.
Seems reasonable to me.
--
Itagaki Takahiro
--
Sen
x27;);
It will be cleaner if we add first_col flag and move it out of
the switch statement.
Other questions I raised before might be matters of preference.
I'd like to here about them form third person.
* name: log_csv_fields vs. csvlog_fields
* when to assign: PGC_POSTMASTER vs. PGC_SIGHUP
cks == true: release all locks including session locks.
| allLocks == false: release all non-session locks.
* Or, we might have one subroutine for LockReleaseSession() and
LockReleaseCurrentOwner(). They have similar codes.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Thu, Feb 10, 2011 at 09:30, Kevin Grittner
wrote:
> Trivial patch attached.
Applied. Thanks!
--
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
files
> and adding a new one just for a few tests didn't seem right. Anyone have an
> idea where they should go or should I just add a new one?
I think you can add advisory_lock.sql for the test.
--
Itagaki Takahiro
advisory4fix.patch
Description: Binary data
--
Sent via pgsql-hackers m
v9r8/index.jsp?topic=/com.ibm.db2.luw.sql.ref.doc/doc/r927.html
I'm not sure it is the best syntax, but at least it's easy to read
for beginners and works with parentheses completion by text editors.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
n retrieve the
values. It's an existing issue, but will be more serious in 9.1.
--
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 on Windows.
* Research libpq + fork() issue. We have a warning in docs:
http://developer.postgresql.org/pgdocs/postgres/libpq-connect.html
| On Unix, forking a process with open libpq connections can lead to
unpredictable results
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list
On Wed, Feb 9, 2011 at 10:17, Andrew Dunstan wrote:
> Isn't this all really a bug fix that should be backpatched, rather than a
> commitfest item?
Sure, but we don't have any bug trackers...
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
a check
> for either kind of infinity and return an error if that's the case? I
Maybe so. It also works if we had infinity on timestamp overflow, but
I've not tested yet. Anyway, we need similar fix for timestamp versions.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgs
I'll include NextCopyFromRawFields() in COPY API patch to complete
raw_fields support in CopyState. (Or, we should also revert changes
related to raw_fields.) However, we'd better postpone jagged csv
support to 9.2. The design is still under discussion.
--
Itagaki Takahiro
--
Sent via
seq_page_cost * pages;
+
+ *startup_cost += baserel->baserestrictcost.startup;
+ cpu_per_tuple = cpu_tuple_cost + baserel->baserestrictcost.per_tuple;
+ run_cost += cpu_per_tuple * 10 * baserel->tuples;
+ *total_cost = *startup_cost + run_cost;
+
+ return stat.st_size;
+}
--
Itagaki T
;infinity', '1
sec') AS a(x);
=# SELECT x FROM generate_series('infinity'::timestamptz, 'infinity',
'1 sec') AS a(x);
> postgres=# SELECT x FROM generate_series(1, 9,-1) AS a(x);
> postgres=# SELECT x FROM generate_series(1, 9,3) AS a(x);
They work as expe
On Sun, Feb 6, 2011 at 23:31, Stephen Frost wrote:
> * Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
>> I think we need to improve postgresql.conf.sample a bit more, especially
>> the long line for #log_csv_fields = '...'. 330 characters in it!
>> #1. Le
full multiset support.
>
> Given PostgreSQL overloading, yes, arrays are multisets as far as
> defining those standard compliant APIs is concerned. AFAIUI.
Yes, I'd like to use overloading.
Choosing arbitrary names increases learning costs for users.
--
Itagaki Takahiro
--
Sent vi
s, or for multisets?
Multisets. But I chose the same function name and syntax because
arrays *are* multisets by definition.
--
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
. We could have array_fusion()
for array types and fusion() for multiset types, but I prefer
overloaded fusion() to have both names.
--
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
ce but uninteresting.
BTW, how do you determine which field is shifted in your broken CSV file?
For example, the case you find "AB,CD,EF" for 2 columns tables.
I could provide a raw CSV reader for jagged files, but you still have to
cook the returned fields into a proper tuple...
--
renamed to target_encoding,
but I prefer file_encoding or remote_encoding.
* CopyState can have conv_proc entity as a member instead of the pointer.
* need_transcoding checks could be replaced with conv_proc IS NULL check.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hacker
tter to remove Windows-specific codes from the first try.
I doubt Windows message queue is the best API in such console-based
application. I hope we could use the same implementation for all
platforms for inter-process/thread communication.
--
Itagaki Takahiro
--
Sent via pgsql-hackers maili
h extensibility.
If COPY FROM, we should implement all the features in copy.c
rather than exported APIs.
--
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
ed previously, is to have a FDW that returns a
> text array from a (possibly irregularly shaped) file.
I remember the text array proposal, but if the extension is written in C,
it can only handle one kind of input files. If another file is broken
in a different way, you need to rewrite the C
typical users
don't want to write functions with C for each kind of input files.
Note that pg_bulkload has a similar feature like as:
CREATE FUNCTION my_function(...) RETURNS record AS ...;
COPY tbl FROM 'file' WITH (make_record_from_line = my_function)
--
Itagaki Takahiro
--
Se
tter. Absent objections, I will also commit it.
I don't have any objections for the patch, but we might also need
to add description about restartpoints into log_checkpoints option.
http://developer.postgresql.org/pgdocs/postgres/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT
--
rsions.
For example, if we have 3 versions of a module below:
NULL unmanaged functions only
v1EXTENSION support with an additional function
v2EXTENSION support with another function.
How do we write upgrading scripts for NULL=>v1, NULL=>v2, and v1=>v2 ?
--
Itagaki Takahiro
-
grade script
for each supported versions? -- if so, it would be nightmare...
--
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
th session and transaction lock
on the same resource at the same time, though we still need to show
exclusive and shared locks in different lines.
--
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
They looks itemized in the sgml files, but will be flattened in
>> complied HTML files.
>
> Not sure what you're referring to here...? Can you elaborate? I'm not
> great with the docs. :/
Could you try to "make html" in the doc directory?
Your new decumentatio
1][1][1][1][1][1]; END; $$;
ERROR: number of array dimensions (6) exceeds the maximum allowed (6)
--
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
ded the patch to the current commitfest for reminder.
https://commitfest.postgresql.org/action/patch_view?id=528
--
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.
Thanks. It's a reasonable reference.
But I reworded it as below, that we are using in other a few places.
The character sets supported by the PostgreSQL server are described in ...
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
pg_start_backup(), and some of checkpoints during recovery
might don't want to sleep.
--
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
pg_extension catalog to return whether the extension is installed,
but it would be better to change the function to return just whole
extensions and JOIN with pg_extension in pg_available_extensions.
(it's the same technique used in pg_stat_replication)
--
Itagaki Takahiro
--
Sent via pgsq
mote") seems
the easiest way if you use an external module.
--
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
ys are adjusted to 1.
I'm not sure what is the consistent behavior for MD arrays. For example,
array_concat() is very strict, but <@ and && operators don't care about
the dimensions. I interpreted the second argument for trim_array() as
a number of "elements", but of
ata type as a
super class of ARRAY and MULTISET. So, it's reasonable that
functions and operators that accept MULTISETs also accept ARRAYs.
For example, we will have cardinality(ARRAY) even if we have
cardinality(MULTISET). Also, trim_array() is in the SQL standard.
I can remove some parts in th
On Thu, Jan 27, 2011 at 22:48, Dimitri Fontaine wrote:
> Itagaki Takahiro writes:
>> I found pg_restore with -c option fails when an extension is created
>> in pg_catalog.
> Nice catch, thank you very much (again) for finding those :)
Seems good.
>> extern bool ext
ate in
BTW, I have a minor comments for the code.
extern bool extension_relocatable_p(Oid ext_oid);
What is "_p" ? Also, we could make the function static
because it is used only in extension.c.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
ared with FOREACH var IN expr.
--
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
mArrayResult() for SLICE has a bit overhead.
If we want to optimize it, we could use memcpy() because slices are
placed in continuous memory. But I'm not sure the worth; I guess
FOREACH will be used with SLICE = 0 in many cases.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsq
pg_dump might need to dump extensions as
"CREATE OR REPLACE EXTENSION" or "CREATE EXTENSION IF NOT EXISTS"
rather than "CREATE EXTENSION".
--
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
* [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, &
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
|
(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
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
;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
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
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/
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 :)
--
?
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
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
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
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
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
,
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
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.
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
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
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
(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
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
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
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
1 - 100 of 891 matches
Mail list logo
