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
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
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
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
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) =>
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
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 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
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?
--
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
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
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
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
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
_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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
| 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
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
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
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
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
'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
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
"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
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
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.
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
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
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
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 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
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
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
| 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
,
* 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
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
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
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
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
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
/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
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.
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
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
;< 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
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
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)
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
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
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
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
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
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
> 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
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
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
>
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
nguish two connections that
differ only >63 bytes.
Do we need another logic to name non-named connections?
For example, md5 hash of the connection string.
--
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
om_variable_classes" in it
might not be needed to parse recovery.conf and extensions.
We would disable them when we parse non-guc configuration files.
Or, we could allow "include" in recovery.conf if we think it is
useful in some cases.
--
Itagaki Takahiro
--
Sent via pgsql-hacker
---
CREATE TABLE partition_20101122 () INHERITS parent
Is it interesting? Comments welcome.
--
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
was some binary read
> classes) and about 50% it's big test case.
I changed the patch's topic to "JDBC".
https://commitfest.postgresql.org/action/patch_view?id=399
Patch reviewers are still wanted.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hacke
the head broken state at the previous commit-fest?
I think that's why the patch becomes so large.
So, our guideline to submit a large patch would be:
* Split patch into commitable sub-patches (2000 lines each),
* But submit a series of patches at once.
Am I understanding correctly?
--
It
nce regression.
[src/backend/utils/adt/pg_locale.c]
-lc_collate_is_c(void)
+lc_collate_is_c(Oid collation)
{
...
+ tp = SearchSysCache1(COLLOID, ObjectIdGetDatum(collation));
...
HERE => if (result >= 0)
return (bool) result;
--
Itagaki Takahiro
--
Sent via
ble. Personally, I prefer "conf".
* Can we export ParseConfigFile() in guc-file.l rather than
parseRecoveryCommandFileLine()? It can solve the issue that unquoted
parameter values in recovery.conf are not recognized. Even if we
won't merge them, just allowing unquoted values wo
lement1, OUT anyelement2, ...)
RETURNS SETOF record
So, we would need a special representation for multi-array unnest().
--
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)
- SELECT row_number() OVER () AS i, v FROM UNNEST($1) AS t(v)
--
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 of the database owner? If we have "autovacuum" role
for autovacuum processes, we could set log_min_messages to DEBUG3 for
only the role with per-user configuration.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
gt; NULL
Will we change the operator's behavior? It would be more
consistent, but incompatible with older server versions.
If impossible, I'll add separated submultiset_of() function
instead of <@ operator for MULTISET supports.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing li
On Wed, Nov 17, 2010 at 10:51, Itagaki Takahiro
wrote:
> On Wed, Nov 17, 2010 at 03:36, Robert Haas wrote:
>> On Tue, Nov 16, 2010 at 1:28 PM, Tom Lane wrote:
>>> I am of the opinion that a run-time-extensible set of plan node types
>>> is merest fantasy. We will nev
it is a waste of time and notational
>> complexity.
>
> I think I agree; and moreover there's been no compelling argument made
> why we would need that for SQL/MED anyway.
I see. I'll cut useless parts from my patch.
--
Itagaki Takahiro
--
Sent via pgsql-hackers maili
t is there the same issue for normal connections?
We can limit max connections per user, but there are no quota for total
memory consumed by the user. It might not be an autovacuum-specifix issue.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
e fields have no names.
=# SELECT (ROW(123, 'ABC', NULL)).*;
ERROR: record type has not been registered
--
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 AS on ahead, but I'd like to
change names of ROW expression in ad-hoc queries.
--
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
ORTED flags.
--
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
fferent
cost models. So, it would be better to encapsulate such operations in 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
On Fri, Nov 12, 2010 at 00:02, Itagaki Takahiro
wrote:
> Postgres supports ARRAY data types well, but there are some
> more array functions in the SQL standard. Also, the standard
> has MULTISET data type, that is an unordered array.
Here is a WIP patch for multiset function supports.
oo clever for its own good.
>
> So committed the rest, plus an additional one-line change to psql's
> print.c to avoid making the two accesses to format->wrap_right_pointer
> inconsistent with each other.
Thanks!
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list
ctor syntax
even now.
--
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 that has many duplicates.
For example, we could use a sorted array of {value, count} pairs.
If we decide to have data type IDs for multiset, I'll go for it (ex. int4,
_int4, and an additional $int4), but it consumes +50% of typoids. If it
is not preferable, only function support might be better
tp://download.oracle.com/docs/cd/B28359_01/server.111/b28286/operators006.htm
--
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
ase products.
Do we need to consider both security hooks and DDL triggers now?
Or, is it enough to design DLL triggers after the hooks are merged?
Low-level hooks might be better for security providers because
SQL-level triggers could be uninstall by superusers.
--
Itagaki Takahiro
--
Sen
= heaptup->t_len;
/*
* If we're gonna fail for oversize tuple, do it right away
--
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
probably not
>> much point.
>
> We're on the same page. I'm implementing the basic cases now and then will
> come up with some benchmarks.
--
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, Nov 1, 2010 at 7:24 PM, Itagaki Takahiro
wrote:
> 1. warning: '' redeclared without dllimport attribute:
> previous dllimport ignored
I discussed with Hiroshi-san about the dllimport issue, and he pointed
out that __declspec(dllexport) and dllwrap cannot work well togeth
101 - 200 of 891 matches
Mail list logo
