Re: [HACKERS] more on out-of-memory
Alvaro Herrera wrote: His question was: is it possible that we're handing a NULL pointer to a %s on fprintf? The involved code looks like this: fprintf(stderr, %s: %lu total in %ld blocks; %lu free (%ld chunks); %lu used\n, set-header.name, totalspace, nblocks, freespace, nchunks, totalspace - freespace); Note that glibc prints (null) if you pass NULL for %s. Others don't. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] More message encoding woes
Peter Eisentraut wrote: In practice you get either the GNU or the Solaris version of gettext, and at least the GNU version can cope with all the encoding names that the currently Windows-only code path produces. It doesn't. On my laptop running Debian testing: hlinn...@heikkilaptop:~$ LC_ALL=fi_FI.UTF-8 gettext gettext: ei riittävästi argumentteja hlinn...@heikkilaptop:~$ LC_ALL=fi_FI.LATIN1 gettext gettext: missing arguments hlinn...@heikkilaptop:~$ LC_ALL=fi_FI.ISO-8859-1 gettext gettext: ei riitt�v�sti argumentteja Using the name for the latin1 encoding in the currently Windows-only mapping table, LATIN1, you get no translation because that name is not recognized by the system. Using the other name ISO-8859-1, it works. LATIN1 is not listed in the output of locale -m either. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] More message encoding woes
On Tuesday 07 April 2009 11:21:25 Heikki Linnakangas wrote: Peter Eisentraut wrote: In practice you get either the GNU or the Solaris version of gettext, and at least the GNU version can cope with all the encoding names that the currently Windows-only code path produces. It doesn't. On my laptop running Debian testing: hlinn...@heikkilaptop:~$ LC_ALL=fi_FI.UTF-8 gettext gettext: ei riittävästi argumentteja hlinn...@heikkilaptop:~$ LC_ALL=fi_FI.LATIN1 gettext gettext: missing arguments That is because no locale by the name fi_FI.LATIN1 exists. hlinn...@heikkilaptop:~$ LC_ALL=fi_FI.ISO-8859-1 gettext gettext: ei riitt�v�sti argumentteja Using the name for the latin1 encoding in the currently Windows-only mapping table, LATIN1, you get no translation because that name is not recognized by the system. Using the other name ISO-8859-1, it works. LATIN1 is not listed in the output of locale -m either. You are looking in the wrong place. What we need is for iconv to recognize the encoding name used by PostgreSQL. iconv --list is the primary hint for that. The locale names provided by the operating system are arbitrary and unrelated. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] More message encoding woes
Hiroshi Inoue wrote: Heikki Linnakangas wrote: I just tried that, and it seems that gettext() does transliteration, so any characters that have no counterpart in the database encoding will be replaced with something similar, or question marks. Assuming that's universal across platforms, and I think it is, using the empty string should work. It also means that you can use lc_messages='ja' with server_encoding='latin1', but it will be unreadable because all the non-ascii characters are replaced with question marks. For something like lc_messages='es_ES' and server_encoding='koi8-r', it will still look quite nice. Attached is a patch I've been testing. Seems to work quite well. It would be nice if someone could test it on Windows, which seems to be a bit special in this regard. Unfortunately it doesn't seem to work on Windows. First any combination of valid lc_messages and non-existent encoding passes the test strcmp(gettext(), ) != 0 . Now that's strange. Can you check what gettext() returns in that case then? Second for example the combination of ja(lc_messages) and ISO-8859-1 passes the the test but the test fails after I changed the last_trans lator part of ja message catalog to contain Japanese kanji characters. Yeah, the inconsistency is not nice. In practice, though, if you try to use an encoding that can't represent kanji characters with Japanese, you're better off falling back to English than displaying strings full of question marks. The same goes for all other languages as well, IMHO. If you're going to fall back to English for some translations (and in practice some is a pretty high percentage) because the encoding is missing a character and transliteration is not working, you might as well not bother translating at all. If we add the dummy translations to all .po files, we could force fallback-to-English in situations like that by including some or all of the non-ASCII characters used in the language in the dummy translation. I'm thinking of going ahead with this approach, without the dummy translation, after we have resolved the first issue on Windows. We can add the dummy translations later if needed, but I don't think anyone will care. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] More message encoding woes
Heikki Linnakangas wrote: Hiroshi Inoue wrote: Heikki Linnakangas wrote: I just tried that, and it seems that gettext() does transliteration, so any characters that have no counterpart in the database encoding will be replaced with something similar, or question marks. Assuming that's universal across platforms, and I think it is, using the empty string should work. It also means that you can use lc_messages='ja' with server_encoding='latin1', but it will be unreadable because all the non-ascii characters are replaced with question marks. For something like lc_messages='es_ES' and server_encoding='koi8-r', it will still look quite nice. Attached is a patch I've been testing. Seems to work quite well. It would be nice if someone could test it on Windows, which seems to be a bit special in this regard. Unfortunately it doesn't seem to work on Windows. First any combination of valid lc_messages and non-existent encoding passes the test strcmp(gettext(), ) != 0 . Now that's strange. Can you check what gettext() returns in that case then? Translated but not converted string. I'm not sure if it's a bug or not. I can see no description what should be returned in such case. Second for example the combination of ja(lc_messages) and ISO-8859-1 passes the the test but the test fails after I changed the last_trans lator part of ja message catalog to contain Japanese kanji characters. Yeah, the inconsistency is not nice. In practice, though, if you try to use an encoding that can't represent kanji characters with Japanese, you're better off falling back to English than displaying strings full of question marks. The same goes for all other languages as well, IMHO. If you're going to fall back to English for some translations (and in practice some is a pretty high percentage) because the encoding is missing a character and transliteration is not working, you might as well not bother translating at all. What is wrong with checking if the codeset is valid using iconv_open()? regards, Hiroshi Inoue -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: XML only working in UTF-8 - Re: [HACKERS] 8.4 open items list
Tom Lane t...@sss.pgh.pa.us writes:
As near as I can tell, every place where you see an explicit cast
between char * and xmlChar * is probably broken. I think we ought
to approach this by refactoring to have all those conversions go
through subroutines, instead of blithely casting.
There is another issue (from sql.ru forum):
seb= select xmlelement(name язык, xmlattributes('русский' as значение));
xmlelement
--
язык значение=#x440;#x443;#x441;#x441;#x43A;#x438;#x439;/
xmlattributes always encode non-latin text as html entities
server_encoding UTF8
client_encoding UTF8
This is strange behavior of libxml... i can't find documentation about this.
http://www.xmlsoft.org/examples/testWriter.c use xmlTextWriterStartDocument
and set output encoding with it. Without it, all non-latin nodes and it values
written correctly (it is UTF-8), except attribute value, this is strange, imho.
xmltype * xmlelement(XmlExprState *xmlExpr, ExprContext *econtext) from xml.c
not use xmlTextWriterStartDocument and return html entities in attribute values.
--
Sergey Burladyan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] More message encoding woes
Hiroshi Inoue wrote: What is wrong with checking if the codeset is valid using iconv_open()? That would probably work as well. We'd have to decide what we'd try to convert from with iconv_open(). Utf-8 might be a safe choice. We don't currently use iconv_open() anywhere in the backend, though, so I'm hesitant to add a dependency for this. GNU gettext() uses iconv, but I'm not sure if that's true for all gettext() implementations. Peter's suggestion seems the best ATM, though. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] More message encoding woes
Peter Eisentraut wrote:
On Tuesday 07 April 2009 11:21:25 Heikki Linnakangas wrote:
Using the name for the latin1 encoding in the currently Windows-only
mapping table, LATIN1, you get no translation because that name is not
recognized by the system. Using the other name ISO-8859-1, it works.
LATIN1 is not listed in the output of locale -m either.
You are looking in the wrong place. What we need is for iconv to recognize
the encoding name used by PostgreSQL. iconv --list is the primary hint for
that.
The locale names provided by the operating system are arbitrary and unrelated.
Oh, ok. I guess we can do the simple fix you proposed then.
Patch attached. Instead of checking for LC_CTYPE == C, I'm checking
pg_get_encoding_from_locale(NULL) == encoding which is more close to
what we actually want. The downside is that
pg_get_encoding_from_locale(NULL) isn't exactly free, but the upside is
that we don't need to keep this in sync with the rules we have in CREATE
DATABASE that enforce that locale matches encoding.
This doesn't include the cleanup to make the mapping table easier to
maintain that Magnus was going to have a look at before I started this
thread.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
*** a/src/backend/utils/mb/mbutils.c
--- b/src/backend/utils/mb/mbutils.c
***
*** 890,896 cliplen(const char *str, int len, int limit)
return l;
}
! #if defined(ENABLE_NLS) defined(WIN32)
static const struct codeset_map {
int encoding;
const char *codeset;
--- 890,896
return l;
}
! #if defined(ENABLE_NLS)
static const struct codeset_map {
int encoding;
const char *codeset;
***
*** 929,935 static const struct codeset_map {
{PG_EUC_TW, EUC-TW},
{PG_EUC_JIS_2004, EUC-JP}
};
! #endif /* WIN32 */
void
SetDatabaseEncoding(int encoding)
--- 929,935
{PG_EUC_TW, EUC-TW},
{PG_EUC_JIS_2004, EUC-JP}
};
! #endif /* ENABLE_NLS */
void
SetDatabaseEncoding(int encoding)
***
*** 946,960 SetDatabaseEncoding(int encoding)
}
/*
! * On Windows, we need to explicitly bind gettext to the correct
! * encoding, because gettext() tends to get confused.
*/
void
pg_bind_textdomain_codeset(const char *domainname, int encoding)
{
! #if defined(ENABLE_NLS) defined(WIN32)
int i;
for (i = 0; i lengthof(codeset_map_array); i++)
{
if (codeset_map_array[i].encoding == encoding)
--- 946,975
}
/*
! * Bind gettext to the correct encoding.
*/
void
pg_bind_textdomain_codeset(const char *domainname, int encoding)
{
! #if defined(ENABLE_NLS)
int i;
+ /*
+ * gettext() uses the encoding specified by LC_CTYPE by default,
+ * so if that matches the database encoding, we don't need to do
+ * anything. This is not for performance, but because if
+ * bind_textdomain_codeset() doesn't recognize the codeset name we
+ * pass it, it will fall back to English and we don't want that to
+ * happen unnecessarily.
+ *
+ * On Windows, though, gettext() tends to get confused so we always
+ * bind it.
+ */
+ #ifndef WIN32
+ if (pg_get_encoding_from_locale(NULL) == encoding)
+ return;
+ #endif
+
for (i = 0; i lengthof(codeset_map_array); i++)
{
if (codeset_map_array[i].encoding == encoding)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Path separator
Tom Lane wrote: Magnus Hagander mag...@hagander.net writes: Tom Lane wrote: In view of the way that canonicalize_path() works, I can't help thinking this is going in precisely the wrong direction. In a way, yes. But canonicalize_path() runs only in the backend, and this is only in the frontend. I think the requirements on the frontend are slightly different than the backend. Just for the record, canonicalize_path does work in the frontend; we have uses of it in psql and pg_ctl. But we have previously decided not to import path.c into libpq, which is where the present issue is, so yes there is a problem with using it. The same objection applies to make_native_path unfortunately. That's what I meant. And yeah, that's true about make_native_path as well. Should we reconsider this decision? But the most important thing is to be consistent within the same path as we report it I think, so we could switch all to forward slashes as well if you think that's better. What I'm concerned about is the prospect that if we do this here, we're going to end up trying to do it all over the frontend code. (And I'm not entirely convinced that it doesn't then propagate into the backend, too, but even just the frontend code is bad enough.) True. I just realized we have a make_native_path() function, I had completely missed that one. So we could possibly use that instead. In the end it does the same thing I'd definitely favor using make_native_path over hand-rolled code. But I guess what I'm suggesting is that it'd be more consistent with our previous choices to apply canonicalize_path instead. I agree that this is probably the best way to do it. The major stumbling block to doing either thing is not wishing to import path.c into libpq. I think that the objection was partially code size and partially namespace pollution (path.c doesn't use pg_ or similar prefixes on its exported names). The latter is no longer a problem on platforms that support exported-name filtering, but that isn't all of them. Could we consider splitting path.c into two parts, that which we want in libpq and that which we don't? On my system (linux), path.o is 5k. libpq.so is 157k. Is adding that size *really* a problem? Also, is there a chance that the linker is smart enough to actually remove the parts of path.o that aren't used in libpq completely, if it's not exported at all? (if the size does matter) If it is, sure, we could split it apart. But fairly large parts of it would be required by both. But I guess the number of symbols would be quite a bit smaller. Is it worth taking a look at exactly what the sizes end up being? Shouldn't be all that much work... //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Path separator
Magnus Hagander wrote: The major stumbling block to doing either thing is not wishing to import path.c into libpq. I think that the objection was partially code size and partially namespace pollution (path.c doesn't use pg_ or similar prefixes on its exported names). The latter is no longer a problem on platforms that support exported-name filtering, but that isn't all of them. Could we consider splitting path.c into two parts, that which we want in libpq and that which we don't? On my system (linux), path.o is 5k. libpq.so is 157k. Is adding that size *really* a problem? Also, is there a chance that the linker is smart enough to actually remove the parts of path.o that aren't used in libpq completely, if it's not exported at all? (if the size does matter) If it is, sure, we could split it apart. But fairly large parts of it would be required by both. But I guess the number of symbols would be quite a bit smaller. Answering myself here: the filesize for the frontend only part is about 2k on this system. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] a few crazy ideas about hash joins
Are there any TODOs here? --- Robert Haas wrote: On Fri, Apr 3, 2009 at 5:10 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Fri, Apr 3, 2009 at 4:29 PM, Tom Lane t...@sss.pgh.pa.us wrote: Correct, but you've got the details all wrong. ?The real problem is that the planner might discard a join path hash(A,B) at level 2 because it loses compared to, say, merge(A,B). ?But when we get to level three, perhaps hash(hash(A,B),C) would've been the best plan due to synergy of the two hashes. ?We'll never find that out unless we keep the inferior hash path around. ?We can certainly do that; the question is what's it going to cost us to allow more paths to survive to the next join level. ?(And I'm afraid the answer may be plenty; it's a combinatorial explosion we're looking at here.) That would be crazy. ?I think doing it the way I suggested is correct, just not guaranteed to catch every case. ?The reality is that even if we took Greg Stark's suggestion of detecting this situation only in the executor, we'd still get some benefit out of this. ?If we take my intermediate approach, we'll catch more cases where this is a win. What you're suggesting here would catch every conceivable case, but at the expense of what I'm sure would be an unacceptable increase in planning time for very limit benefit. Maybe, maybe not. ?I've seen plenty of plans that have several mergejoins stacked up on top of each other with no intervening sorts. There is 0 chance that the planner would have produced that if it thought that it had to re-sort at each level; something else would have looked cheaper. ?I think that your proposals will end up getting very little of the possible benefit, because the planner will fail to choose plan trees in which the optimization can be exploited. Well, I'm all ears if you have suggestions for improvement. For sorts, we use PathKeys to represent the ordering of each path and keep the paths for each set of pathkeys. By analogy, we could maintain a list of PathHash structures for each path representing the tables that had already been hashed. add_path() would then have to consider both the PathHash structures and the PathKey structures before concluding that a path was definitely worse than some path previously found. At each level of the join tree, we'd need to truncate PathHash structures that provably have no further use (e.g. on a base table that does not appear again above the level of the join already planned) to avoid keeping around paths that appeared to be better only because we didn't know that the paths they have hashed are worthless in practice. Maybe that wouldn't even be that expensive, actually, because there will be lots of cases where you know the relevant table doesn't appear elsewhere in the query and not save any extra paths. But I think we'd have to write the code and benchmark it to really know. I guess the reason I'm not too worked up about this is because my experience is that the planner nearly always prefers hash joins on small tables, even when an index is present - the queries I'm worried about optimizing don't need any additional encouragement to use hash joins; they're doing it already. But certainly it doesn't hurt to see how many cases we can pick up. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] More message encoding woes
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Hiroshi Inoue wrote: What is wrong with checking if the codeset is valid using iconv_open()? That would probably work as well. We'd have to decide what we'd try to convert from with iconv_open(). The problem I have with that is that you are now guessing at *two* platform-specific encoding names not one, plus hoping there is a conversion between the two. If we knew the encoding name embedded in the .mo file we wanted to use, then it would be sensible to try to use that as the source codeset. GNU gettext() uses iconv, but I'm not sure if that's true for all gettext() implementations. Yeah, that's another problem. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Path separator
Magnus Hagander wrote:
Magnus Hagander wrote:
The major stumbling block to doing either thing is not wishing to import
path.c into libpq. I think that the objection was partially code size
and partially namespace pollution (path.c doesn't use pg_ or similar
prefixes on its exported names). The latter is no longer a problem on
platforms that support exported-name filtering, but that isn't all of
them. Could we consider splitting path.c into two parts, that which we
want in libpq and that which we don't?
On my system (linux), path.o is 5k. libpq.so is 157k. Is adding that
size *really* a problem?
Also, is there a chance that the linker is smart enough to actually
remove the parts of path.o that aren't used in libpq completely, if it's
not exported at all? (if the size does matter)
If it is, sure, we could split it apart. But fairly large parts of it
would be required by both. But I guess the number of symbols would be
quite a bit smaller.
Answering myself here: the filesize for the frontend only part is
about 2k on this system.
Long meeting, time for coding.. :-) Here's a rough patch. Is this about
what you had in mind?
//Magnus
diff --git a/src/include/port.h b/src/include/port.h
index 0557dd2..c84f0d6 100644
--- a/src/include/port.h
+++ b/src/include/port.h
@@ -28,8 +28,15 @@ extern char *last_dir_separator(const char *filename);
extern char *first_path_separator(const char *pathlist);
extern void join_path_components(char *ret_path,
const char *head, const char *tail);
+extern void trim_directory(char *path);
+extern void trim_trailing_separator(char *path);
extern void canonicalize_path(char *path);
extern void make_native_path(char *path);
+#ifdef WIN32
+extern char *skip_drive(const char *path);
+#else
+#define skip_drive(path) (path)
+#endif
extern bool path_contains_parent_reference(const char *path);
extern bool path_is_prefix_of_path(const char *path1, const char *path2);
extern const char *get_progname(const char *argv0);
diff --git a/src/interfaces/libpq/Makefile b/src/interfaces/libpq/Makefile
index 3b9df76..02a240d 100644
--- a/src/interfaces/libpq/Makefile
+++ b/src/interfaces/libpq/Makefile
@@ -34,6 +34,7 @@ OBJS= fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o \
fe-protocol2.o fe-protocol3.o pqexpbuffer.o pqsignal.o fe-secure.o \
libpq-events.o \
md5.o ip.o wchar.o encnames.o noblock.o pgstrcasecmp.o thread.o \
+ path_fe.o \
$(filter crypt.o getaddrinfo.o inet_aton.o open.o snprintf.o strerror.o strlcpy.o win32error.o, $(LIBOBJS))
ifeq ($(PORTNAME), cygwin)
@@ -80,7 +81,7 @@ backend_src = $(top_srcdir)/src/backend
# For port modules, this only happens if configure decides the module
# is needed (see filter hack in OBJS, above).
-crypt.c getaddrinfo.c inet_aton.c noblock.c open.c pgstrcasecmp.c snprintf.c strerror.c strlcpy.c thread.c win32error.c pgsleep.c: % : $(top_srcdir)/src/port/%
+crypt.c getaddrinfo.c inet_aton.c noblock.c open.c path_fe.c pgstrcasecmp.c snprintf.c strerror.c strlcpy.c thread.c win32error.c pgsleep.c: % : $(top_srcdir)/src/port/%
rm -f $@ $(LN_S) $ .
md5.c ip.c: % : $(backend_src)/libpq/%
diff --git a/src/interfaces/libpq/fe-secure.c b/src/interfaces/libpq/fe-secure.c
index 8383f2a..a68baee 100644
--- a/src/interfaces/libpq/fe-secure.c
+++ b/src/interfaces/libpq/fe-secure.c
@@ -600,6 +600,7 @@ client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
strncpy(fnbuf, conn-sslcert, sizeof(fnbuf));
else
snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, USER_CERT_FILE);
+ canonicalize_path(fnbuf);
/*
* OpenSSL = 0.9.8 lacks error stack handling, which means it's likely to
@@ -716,6 +717,7 @@ client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
/* No PGSSLKEY specified, load default file */
snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, USER_KEY_FILE);
}
+ canonicalize_path(fnbuf);
if (fnbuf[0] != '\0')
{
@@ -1016,6 +1018,7 @@ initialize_SSL(PGconn *conn)
strncpy(fnbuf, conn-sslrootcert, sizeof(fnbuf));
else
snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, ROOT_CERT_FILE);
+ canonicalize_path(fnbuf);
if (stat(fnbuf, buf) == 0)
{
@@ -1038,6 +1041,7 @@ initialize_SSL(PGconn *conn)
strncpy(fnbuf, conn-sslcrl, sizeof(fnbuf));
else
snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, ROOT_CRL_FILE);
+ canonicalize_path(fnbuf);
/* setting the flags to check against the complete CRL chain */
if (X509_STORE_load_locations(cvstore, fnbuf, NULL) == 1)
diff --git a/src/port/Makefile b/src/port/Makefile
index f03a17a..f515847 100644
--- a/src/port/Makefile
+++ b/src/port/Makefile
@@ -31,7 +31,7 @@ override CPPFLAGS := -I$(top_builddir)/src/port -DFRONTEND $(CPPFLAGS)
LIBS += $(PTHREAD_LIBS)
OBJS = $(LIBOBJS) chklocale.o copydir.o dirmod.o exec.o noblock.o path.o \
- pgsleep.o pgstrcasecmp.o qsort.o qsort_arg.o sprompt.o thread.o
+ path_fe.o pgsleep.o pgstrcasecmp.o qsort.o qsort_arg.o sprompt.o thread.o
ifneq (,$(filter $(PORTNAME),cygwin win32))
Re: [HACKERS] Path separator
Magnus Hagander mag...@hagander.net writes: Tom Lane wrote: The major stumbling block to doing either thing is not wishing to import path.c into libpq. I think that the objection was partially code size and partially namespace pollution (path.c doesn't use pg_ or similar prefixes on its exported names). The latter is no longer a problem on platforms that support exported-name filtering, but that isn't all of them. Could we consider splitting path.c into two parts, that which we want in libpq and that which we don't? On my system (linux), path.o is 5k. libpq.so is 157k. Is adding that size *really* a problem? I'm more worried about the external dependencies pulled in by the path-discovery stuff (geteuid for instance). None of that is code that libpq needs at all. Also, is there a chance that the linker is smart enough to actually remove the parts of path.o that aren't used in libpq completely, if it's not exported at all? (if the size does matter) The normal expectation is that .o files are the unit of linking. There might be a platform or two that is smarter, but they are not the norm. Since I'm the one who's hot about this, I'm willing to do the work. Do you agree that canonicalize_path and make_native_path are all that we want to push into libpq for now? If so, I'll rename them to pg_..._path and push them into a separate source file. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] a few crazy ideas about hash joins
On Tue, Apr 7, 2009 at 9:55 AM, Bruce Momjian br...@momjian.us wrote: Are there any TODOs here? I'd say that all of the items listed in my original email could be TODOs. I'm planning to work on as many of them as I have time for. Ramon Lawrence is also working on some related ideas, as discussed upthread. AFAICS no one has expressed the idea that anything that's been talked about is a bad idea, so it's just a question of finding enough round tuits. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Path separator
I wrote: Since I'm the one who's hot about this, I'm willing to do the work. Belay that ... I'll review your patch instead, later today sometime. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug of ALTER TABLE DROP CONSTRAINT
Nikhil Sontakke wrote: Hi, We've discussed before the idea that NOT NULL constraints should be explicitly represented in pg_constraint, just like general CHECK constraints (this would allow them to be named, have sane inheritance behavior, etc). If we had that, then pg_attribute.attnotnull could indicate the OR of there is a NOT NULL on this column and there is a pkey constraint on this column, and you'd just have to recompute it properly after dropping either kind of constraint. Not happening for 8.4, but maybe someday someone will get around to it. Warrants an entry in the TODO items list: * make NOT NULL constraints have pg_constraint entries, just like CHECK constraints This is now a TODO item (I just updated the description): Store the constraint names of NOT NULL constraints Currently NOT NULL constraints are stored in pg_attribute without any designation of their origins, e.g. primary keys. One manifest problem is that dropping a PRIMARY KEY constraint does not remove the NOT NULL constraint designation. * http://archives.postgresql.org/message-id/19768.1238680...@sss.pgh.pa.us -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug of ALTER TABLE DROP CONSTRAINT
Bruce Momjian br...@momjian.us writes: Nikhil Sontakke wrote: Warrants an entry in the TODO items list: * make NOT NULL constraints have pg_constraint entries, just like CHECK constraints This is now a TODO item (I just updated the description): Store the constraint names of NOT NULL constraints I was intending to do that yesterday, but lost interest after discovering how many duplicate, obsolete, and/or mutually contradictory TODO entries there are related to constraints. That needs to be cleaned up and consolidated sometime. Also, what is wrong with the precise statement of the TODO item that Nikhil gave? The one you gave would encourage someone to waste time on a 100% wrong implementation (like adding a constraint name column to pg_attribute). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] string_to_array with empty input
Did I miss the exciting conclusion or did this drift silently off radar? I seem to recall three options: 1. Leave as is. Arguments: least effort, no backward compatibility issues, since array_to_string evaluate both an array with single empty string and an array with no elements to an empty string, string_to_array on empty strings is ambiguous so we'll call it null. But: means that the result of null input and non-null empty-string both result in null output, requires everyone to explicitly handle empty strings (with the side effect that they really know what the result will be) instead of helping the majority of users. Requires: documentation change to accurately describe function's behavior. 2. Change function to return an array. Arguments: Distinguishes null from non-null input, easier coding for most cases, perhaps a less surprising result. But: not backward compatible, requires somewhat arbitrary decision on correct return value. Requires: code change/testing, documentation updates. In scenario 2, there were two options: 2a. Return zero-element array. 2b. Return array with single empty-string element. My impression was that among the change options, 2b had the most support (it is the most useful for the use-cases I've encountered so it gets my vote). If the consensus is to change the function, it may be too late for 8.4. But the documentation could be updated to reflect current and planned behavior. Cheers, Steve -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] string_to_array with empty input
Steve Crawford wrote: Did I miss the exciting conclusion or did this drift silently off radar? it was pretty well split between the options. tabled for another time. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] string_to_array with empty input
On Apr 7, 2009, at 8:07 AM, Steve Crawford wrote: In scenario 2, there were two options: 2a. Return zero-element array. 2b. Return array with single empty-string element. My impression was that among the change options, 2b had the most support (it is the most useful for the use-cases I've encountered so it gets my vote). If the consensus is to change the function, it may be too late for 8.4. But the documentation could be updated to reflect current and planned behavior. +1 David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] NaN support in NUMERIC data type
Hi, I've just noticed that the NUMERIC input function special cases NaN values differently to the floating point input functions. For example the following are all accepted (on my system anyway): SELECT 'NaN'::float8; SELECT ' NaN'::float8; SELECT 'NaN '::float8; SELECT '+NaN'::float8; SELECT '-NaN'::float8; whereas only the first is OK for numeric. Is this deliberate? A quick check of utils/adt/numeric.c would suggest that it's been special cased as a optimisation so we don't allocate a numeric value in set_var_from_str() unless we need to. As a side note; I'm only really interested in the leading/trailing spaces. I only noticed the leading plus/minus sign when reading the code and think it's probably better if a NaN is rejected if it has a leading sign. I think it would be better if it was consistent with FLOAT, not sure how to do this in a platform independent way though. I could submit a patch if you want; I'm unsure whether it's better to duplicate code in numeric_in, do slightly more work and allocate memory for NaN's when not strictly needed, or remove knowledge of NumericVar from numeric_in altogether and push code into set_var_from_str. Comments? -- Sam http://samason.me.uk/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Solution of the file name problem of copy on windows.
Hi Tom-san.
I want to solve one problem before the release of 8.4.
However, since it also seems to be the new feature,
if not enough for 8.4, you may suggest that it is 8.5.
In Japan, the local file name of a server is dealt with by SJIS.
The example present Postgres...
server_encoding = UTF-8
client_encoding = SJIS
At this time, a copy file name is UTF-8. It was troubled by handling.:-(
Then, I make this proposal patch.
regression test
===
All 120 tests passed.
===
as for database is UTF-8.
HIROSHI=# \l
データベース一覧
名前| 所有者 | エンコーディング | Collation | Ctype | アクセス権
---+-+--+---+---+---
--
HIROSHI | HIROSHI | UTF8 | C | C |
eucdb | HIROSHI | EUC_JP | C | C |
HIROSHI=# create table 日本語てすと (きー text);
CREATE TABLE
HIROSHI=# insert into 日本語てすと values('わーい');
INSERT 0 1
HIROSHI=# copy 日本語てすと to 'C:/tmp/日本語UTF8.txt';
COPY 1
HIROSHI=# delete from 日本語てすと;
DELETE 1
HIROSHI=# copy 日本語てすと from 'C:/tmp/日本語UTF8.txt';
COPY 1
HIROSHI=# select * from 日本語てすと;
きー
わーい
(1 行)
as for database is eucjp.
HIROSHI=# \c eucdb
psql (8.4devel)
データベース eucdb に接続しました。.
eucdb=# \d
リレーションの一覧
スキーマ | 名前 | 型 | 所有者
--+--+---+-
public | 日本語てすと | table | HIROSHI
(1 行)
eucdb=# select * from 日本語てすと;
きー
わーい
(1 行)
eucdb=# copy 日本語てすと to 'C:/tmp/日本語eucdb.txt';
COPY 1
eucdb=# delete from 日本語てすと;
DELETE 1
eucdb=# copy 日本語てすと from 'C:/tmp/日本語eucdb.txt';
COPY 1
eucdb=# select * from 日本語てすと;
きー
わーい
(1 行)
C:\tmpdir 日本語*
ドライブ C のボリューム ラベルは SYS です
ボリューム シリアル番号は 1433-2C7C です
C:\tmp のディレクトリ
2009/04/07 13:58 8 日本語eucdb.txt
2009/04/07 13:58 8 日本語utf8.txt
2 個のファイル 16 バイト
It seems that it is very comfortable. !!
What do you think?
Regards,
Hiroshi Saito
copy_patch3
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
Re: [HACKERS] NaN support in NUMERIC data type
Sam Mason s...@samason.me.uk writes: I've just noticed that the NUMERIC input function special cases NaN values differently to the floating point input functions. For example the following are all accepted (on my system anyway): SELECT 'NaN'::float8; SELECT ' NaN'::float8; SELECT 'NaN '::float8; SELECT '+NaN'::float8; SELECT '-NaN'::float8; whereas only the first is OK for numeric. Is this deliberate? Well, the +- part must be an artifact of your strtod() implementation; our own code isn't doing anything to accept that. I think it's pretty bogus --- NaNs do not have signs. IIRC, the explicit support for leading/trailing spaces is something that we added in float8in long after numeric_in was written, and I think just nobody thought about numeric at the time. But it's clearly inconsistent to allow spaces around a regular value but not a NaN. Possibly the logic for leading/trailing spaces could be pulled out of set_var_from_str and executed in numeric_in instead? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Solution of the file name problem of copy on windows.
Hiroshi Saito z-sa...@guitar.ocn.ne.jp writes: I want to solve one problem before the release of 8.4. However, since it also seems to be the new feature, if not enough for 8.4, you may suggest that it is 8.5. I'm not too clear on what this is really supposed to accomplish, but we are hardly going to put code like that into every single file access in Postgres, which is what seems to be the logical implication. Shouldn't we just tell people to use a database encoding that matches their system environment? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Array types
This is something the client code would request (or not). It would not be sensible to try to force it from the server side, since if the client doesn't request it it's likely that the client wouldn't understand the data format. Cheers for the quick reply, any chance of a pointer to the protocol where the client specifies the return type(s) so i can check the client code (mainly jdbc) to see what is going on? Thanks JOHN -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Array types
Does libpqtypes pass the array over the wire as an array? Ideally i'd like to do this with jdbc, but might give me a pointer... Thanks - Original Message - From: Andrew Chernow a...@esilo.com To: John Lister john.lister...@kickstone.com Cc: pgsql-hackers@postgresql.org Sent: Tuesday, April 07, 2009 8:15 PM Subject: Re: [HACKERS] Array types John Lister wrote: They all return arrays as text, is it possible to configure postgresql to return an array in native form (does postgresql support such a thing)? This is using both the simple and extended query forms - i couldn't see a way to say what return type i wanted in the protocol docs... You need libpqtypes (client-side library). It requires a new 8.4 feature called libpq-events, but there is an 8.3 patch available. If you willing to patch your 8.3.5 libpq client, than this should meet your needs. Downloads: http://pgfoundry.org/projects/libpqtypes/ Documentation: http://libpqtypes.esilo.com/ For arrays, libpqtypes gives you a PGresult where each tuple is an array item. For composite arrays, each composite field is a PGresult field. This would seem much better in terms of performance, both size and speed(conversion). That is true. Our testing has proven this. It also reduces the overall coding effort. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Update PL interpreters for 8.4
Dave Page wrote: The MSVC++ build system is a little lacking in it's ability to build against different versions of Perl and TCL. The attached patch doesn't fix that (unfortunately), but does update the hard-coded library names so we can use Perl 5.10 and TCL 8.5 with PG 8.4. Applied, thanks. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Array types
On Tue, Apr 7, 2009 at 3:35 PM, John Lister john.lister...@kickstone.com wrote: Does libpqtypes pass the array over the wire as an array? Ideally i'd like to do this with jdbc, but might give me a pointer... We send/receive the server's array format. This is not quite a C array, and is definitely not a java array. It's a packed postgres specific (network byte order) format. It is much faster and tighter than text in some cases however. We present an interface to copy C arrays to postgres style formats such as: PGarray a; PQgetf(res, tuple_num, %int4[], field_num, a); This will 'pop' a result out of your result that presents the array internals (which you could then loop). merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sort a column that does not exist
Hi, I think I solved the problem in the parser and the planner, but I'm
stuck in the executor, I think is in the ExecSort function on nodeSort
around this code:
/*
* Scan the subplan and feed all the tuples to tuplesort.
*/
for (;;)
{
slot = ExecProcNode(outerNode);
if (TupIsNull(slot))
break;
tuplesort_puttupleslot(tuplesortstate, slot);
}
Now, when the server get in that loop it hangs out, Would I have to add
something that identifies the extra column? or will I have to include
somewhere in the tuplesort the column?
2009/4/2 Werner Echezuria werc...@gmail.com
Hi, the problem goes on. I think the problem is in the planner.c on
grouping_planner function, because when I do a regular sort it gets to it:
/*
* If we were not able to make the plan come out in the right order,
add
* an explicit sort step.
*/
if (parse-sortClause)
{
if (!pathkeys_contained_in(sort_pathkeys, current_pathkeys))
{
result_plan = (Plan *) make_sort_from_pathkeys(root,
result_plan,
sort_pathkeys,
limit_tuples);
current_pathkeys = sort_pathkeys;
}
}
and do the make_sort_from_pathkeys, but when I do the sort by grmemb it
does not. So I change it in order to pass through make_sort_from_pathkey,
but it drops an error like this invalid attnum, so when I go to heaptuple
and force to get to ObjectIdGetDatum in heap_getsysattr, the server hang
out. What can I do? How can I assign a valid attrnum?
2009/4/1 Hitoshi Harada umi.tan...@gmail.com
2009/4/1 Werner Echezuria werc...@gmail.com:
As you can see if someone do this: SELECT * FROM table WHERE
field=some_value ORDER BY grmemb, postgresql creates a new target entry
and
then assigned to the targetlist as a sort node. I know that it creates
the
node on the parser, but it does not work, it seems the executor don't
see
it.
See include/nodes/primnodes.h around line 1075:
boolresjunk;/* set to true to eliminate
the attribute from
* final
target list */
If the TargetEntry is set resjunk = false, the final result is
filtered as junk. So more accurately the executor sees but drops it.
How could I sort a column like this?, I know i'm missing something, but
i
just don't see it. What is the process to sort a column?
Use makeTargetEntry in makefuncs.c
TargetEntry *
makeTargetEntry(Expr *expr,
AttrNumber resno,
char *resname,
bool resjunk)
by the 4th argument you can set resjunk = false if you don't want it
to be in the result.
Regards,
--
Hitoshi Harada
Re: [HACKERS] More message encoding woes
Peter Eisentraut wrote: On Tuesday 07 April 2009 13:09:42 Heikki Linnakangas wrote: Patch attached. Instead of checking for LC_CTYPE == C, I'm checking pg_get_encoding_from_locale(NULL) == encoding which is more close to what we actually want. The downside is that pg_get_encoding_from_locale(NULL) isn't exactly free, but the upside is that we don't need to keep this in sync with the rules we have in CREATE DATABASE that enforce that locale matches encoding. I would have figured we can skip this whole thing when LC_CTYPE != C, because it should be guaranteed that LC_CTYPE matches the database encoding in this case, no? Yes, except if pg_get_encoding_from_locale() couldn't figure out what PG encoding LC_CTYPE corresponds to. We let CREATE DATABASE to go ahead in that case, trusting that the user knows what he's doing. I suppose we can extend that trust to this case too, and assume that the encoding of LC_CTYPE actually matches the database encoding. Or if the encoding is UTF-8 and you're running on Windows, although on Windows we want to always call bind_textdomain_codeset(). Or if the database encoding is SQL_ASCII, although in that case we don't want to call bind_textdomain_codeset() either. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Array types
John Lister wrote: Cheers, nice to know it is possible... Now to see if i can get java/python to do the same :) or to use a modified libpq somehow... If performance is your concern, you would probably get the best results using the languages C glue interfrace. For instance, in java I think you would want to create a JNI wrapper to libpqtypes that converts PGarray to a java array. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Array types
Hi, using v8.3.5 and a number of client libraries (java, python, pgadmin) and playing about with arrays. They all return arrays as text, is it possible to configure postgresql to return an array in native form (does postgresql support such a thing)? This is using both the simple and extended query forms - i couldn't see a way to say what return type i wanted in the protocol docs... This would seem much better in terms of performance, both size and speed(conversion). Thanks -- Got needs? Get Goblin'! - http://www.pricegoblin.co.uk/
Re: [HACKERS] Array types
On Tue, Apr 7, 2009 at 3:11 PM, Tom Lane t...@sss.pgh.pa.us wrote: John Lister john.lister...@kickstone.com writes: Hi, using v8.3.5 and a number of client libraries (java, python, pgadmin) and playing about with arrays. They all return arrays as text, is it possible to configure postgresql to return an array in native form (does postgresql support such a thing)? This is something the client code would request (or not). It would not be sensible to try to force it from the server side, since if the client doesn't request it it's likely that the client wouldn't understand the data format. unless, of course, you are using libpqtypes :D http://libpqtypes.esilo.com/ merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Array types
John Lister john.lister...@kickstone.com writes: Hi, using v8.3.5 and a number of client libraries (java, python, pgadmin) and playing about with arrays. They all return arrays as text, is it possible to configure postgresql to return an array in native form (does postgresql support such a thing)? This is something the client code would request (or not). It would not be sensible to try to force it from the server side, since if the client doesn't request it it's likely that the client wouldn't understand the data format. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Closing some 8.4 open items
Tom Lane wrote: Greg Stark st...@enterprisedb.com writes: On Sun, Apr 5, 2009 at 6:54 PM, Robert Haas robertmh...@gmail.com wrote: I'm excited about some of them, but not to the point of not wanting to ship beta. ?So +1 for removing them as per your suggestions. I'm somewhat excited about posix_fadvise but my general feeling was that it was best to do nothing anyways. Yeah. One of the things in the back of my mind is that the planner is going to prefer bitmap scans anyway for anything that fetches more than a very few rows. So it's not clear that prefetching plain indexscans is going to buy enough to justify a whole lotta work or ugliness there. I'm content to throw this one on TODO. I am not inclined to add a TODO until we see actual value in doing it. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] custom tsearch2 parsers
Kevin Grittner kevin.gritt...@wicourts.gov wrote: It appears that I need to put together a custom parser for tsearch2. Reality check: I need to find start and end locations for all matches of a regular expression in a text object, very similar to what is done by setup_regexp_matches in regexp.c for the regexp_split_* functions. I'm assuming this is copy/paste for 8.4 and prior? (It would be nice to have a function in regexp.c to return the information using the existing code, but that's too late for 8.4 and not a candidate for back patching?) Just thought I'd confirm before duplicating that much code. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Array types
Cheers, nice to know it is possible... Now to see if i can get java/python to do the same :) or to use a modified libpq somehow... Merlin Moncure wrote: On Tue, Apr 7, 2009 at 3:35 PM, John Lister john.lister...@kickstone.com wrote: Does libpqtypes pass the array over the wire as an array? Ideally i'd like to do this with jdbc, but might give me a pointer... We send/receive the server's array format. This is not quite a C array, and is definitely not a java array. It's a packed postgres specific (network byte order) format. It is much faster and tighter than text in some cases however. We present an interface to copy C arrays to postgres style formats such as: PGarray a; PQgetf(res, tuple_num, %int4[], field_num, a); This will 'pop' a result out of your result that presents the array internals (which you could then loop). merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Backup -- Feridun Türk
İ have two question, Backup and restore with C# (windos form) interface, or postgre scripts? -- Regards, Feridun Türk
Re: [HACKERS] a few crazy ideas about hash joins
Robert Haas wrote: On Tue, Apr 7, 2009 at 9:55 AM, Bruce Momjian br...@momjian.us wrote: Are there any TODOs here? I'd say that all of the items listed in my original email could be TODOs. I'm planning to work on as many of them as I have time for. Ramon Lawrence is also working on some related ideas, as discussed upthread. AFAICS no one has expressed the idea that anything that's been talked about is a bad idea, so it's just a question of finding enough round tuits. OK, would you please add them to the Index/Hash section of the TODO list; I am afraid I will not do the justice. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug of ALTER TABLE DROP CONSTRAINT
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Nikhil Sontakke wrote: Warrants an entry in the TODO items list: * make NOT NULL constraints have pg_constraint entries, just like CHECK constraints This is now a TODO item (I just updated the description): Store the constraint names of NOT NULL constraints I was intending to do that yesterday, but lost interest after discovering how many duplicate, obsolete, and/or mutually contradictory TODO entries there are related to constraints. That needs to be cleaned up and consolidated sometime. Also, what is wrong with the precise statement of the TODO item that Nikhil gave? The one you gave would encourage someone to waste time on a 100% wrong implementation (like adding a constraint name column to pg_attribute). I felt the original wording would be unclear in explaining the problem behavior; you are right the original wording was clearer for correcting the problem. This updated wording works for both audiences, I think: Move NOT NULL constraint information to pg_constraint Currently NOT NULL constraints are stored in pg_attribute without any designation of their origins, e.g. primary keys. One manifest problem is that dropping a PRIMARY KEY constraint does not remove the NOT NULL constraint designation. * http://archives.postgresql.org/message-id/19768.1238680...@sss.pgh.pa.us -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] More message encoding woes
On Tuesday 07 April 2009 13:09:42 Heikki Linnakangas wrote: Patch attached. Instead of checking for LC_CTYPE == C, I'm checking pg_get_encoding_from_locale(NULL) == encoding which is more close to what we actually want. The downside is that pg_get_encoding_from_locale(NULL) isn't exactly free, but the upside is that we don't need to keep this in sync with the rules we have in CREATE DATABASE that enforce that locale matches encoding. I would have figured we can skip this whole thing when LC_CTYPE != C, because it should be guaranteed that LC_CTYPE matches the database encoding in this case, no? Other than that, I think this patch is good. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Path separator
Magnus Hagander mag...@hagander.net writes: Answering myself here: the filesize for the frontend only part is about 2k on this system. Long meeting, time for coding.. :-) Here's a rough patch. Is this about what you had in mind? Hm, this seems to make the namespace pollution problem worse not better, because of de-staticizing so many functions. I guess we could stick pg_ prefixes on all of them. That's a bit ugly; anybody have a better idea? It might be that it'd be better to push a couple more of the simple path-munging functions (like join_path_components) over into the new file, so as to have a more logical division of responsibilities. In my mind the two key areas here are path syntax knowledge and extracting absolute paths from environmental information. The second part seems to be the one that doesn't belong on the frontend side. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] a few crazy ideas about hash joins
On Tue, Apr 7, 2009 at 5:11 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Tue, Apr 7, 2009 at 9:55 AM, Bruce Momjian br...@momjian.us wrote: Are there any TODOs here? I'd say that all of the items listed in my original email could be TODOs. I'm planning to work on as many of them as I have time for. Ramon Lawrence is also working on some related ideas, as discussed upthread. AFAICS no one has expressed the idea that anything that's been talked about is a bad idea, so it's just a question of finding enough round tuits. OK, would you please add them to the Index/Hash section of the TODO list; I am afraid I will not do the justice. I think perhaps Optimizer / Executor would be more appropriate, since these are not about hash indices but rather about hash joins. I will look at doing that. Also I think the last item under Index / Hash is actually NOT done, and belongs in the main index section rather than Index / Hash. The first item in the Index / Hash section doesn't really look like a TODO, or at the very least it's unclear what the action item is supposed to be. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] a few crazy ideas about hash joins
Robert Haas wrote: On Tue, Apr 7, 2009 at 5:11 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Tue, Apr 7, 2009 at 9:55 AM, Bruce Momjian br...@momjian.us wrote: Are there any TODOs here? I'd say that all of the items listed in my original email could be TODOs. ?I'm planning to work on as many of them as I have time for. Ramon Lawrence is also working on some related ideas, as discussed upthread. ?AFAICS no one has expressed the idea that anything that's been talked about is a bad idea, so it's just a question of finding enough round tuits. OK, would you please add them to the Index/Hash section of the TODO list; ?I am afraid I will not do the justice. I think perhaps Optimizer / Executor would be more appropriate, since these are not about hash indices but rather about hash joins. I will look at doing that. Yes, please. Also I think the last item under Index / Hash is actually NOT done, and belongs in the main index section rather than Index / Hash. Yep, I didn't realize that editing Index also does the subsections, while editing the subsections doesn't edit the upper level. The first item in the Index / Hash section doesn't really look like a TODO, or at the very least it's unclear what the action item is supposed to be. Yep, remove, thanks. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] New trigger option of pg_standby
On Fri, Apr 3, 2009 at 5:42 AM, Fujii Masao masao.fu...@gmail.com wrote: Here is the patch; - Smart failover is chosen if the trigger file labeled smart or an empty one exists. - Fast failover is chosen if the trigger file labeled fast exists, the signal (SIGUSR1 or SIGINT) is received or the wait timeout happens. After some further thoughts, +1 for this approach too. I think you imply 'containing smart' not 'labeled smart'. Labeled is confusing IMHO. +1 to change the default behaviour too. All the people discovering the current behaviour are totally surprised. -- Guillaume -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A renewed plea for inclusion of zone.tab
On Mon, Apr 06, 2009 at 08:48:55PM -0400, Tom Lane wrote: Andrew Gierth and...@tao11.riddles.org.uk writes: At the VERY LEAST, can we PLEASE have the zone.tab file INSTALLED WHERE IT BELONGS rather than simply ignored, so that even if further requests to include the information in a system view go unheard by -hackers, I can at least provide a pgfoundry module or something to do the job. I still see no point in this unless we expose the information in pg_timezone_names, which requires rather more than a one-line patch. If you want to prepare such a patch and put it in the queue for 8.5, go right ahead. There's really no point, and a lot of good stuff lost, in leaving this thing out. It's not like the few kilobytes it takes up could possibly matter in the grand scheme of things. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Array types
John Lister wrote: They all return arrays as text, is it possible to configure postgresql to return an array in native form (does postgresql support such a thing)? This is using both the simple and extended query forms - i couldn't see a way to say what return type i wanted in the protocol docs... You need libpqtypes (client-side library). It requires a new 8.4 feature called libpq-events, but there is an 8.3 patch available. If you willing to patch your 8.3.5 libpq client, than this should meet your needs. Downloads: http://pgfoundry.org/projects/libpqtypes/ Documentation: http://libpqtypes.esilo.com/ For arrays, libpqtypes gives you a PGresult where each tuple is an array item. For composite arrays, each composite field is a PGresult field. This would seem much better in terms of performance, both size and speed(conversion). That is true. Our testing has proven this. It also reduces the overall coding effort. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A renewed plea for inclusion of zone.tab
David Fetter wrote: On Mon, Apr 06, 2009 at 08:48:55PM -0400, Tom Lane wrote: Andrew Gierth and...@tao11.riddles.org.uk writes: At the VERY LEAST, can we PLEASE have the zone.tab file INSTALLED WHERE IT BELONGS rather than simply ignored, so that even if further requests to include the information in a system view go unheard by -hackers, I can at least provide a pgfoundry module or something to do the job. I still see no point in this unless we expose the information in pg_timezone_names, which requires rather more than a one-line patch. If you want to prepare such a patch and put it in the queue for 8.5, go right ahead. There's really no point, and a lot of good stuff lost, in leaving this thing out. It's not like the few kilobytes it takes up could possibly matter in the grand scheme of things. Agreed, it seems to me that a patch to install zone.tab during make install could be applied at this time (before beta so that packagers don't complain that we didn't give them time to fix their file lists). A more complete patch can be discussed for 8.5. ... though there's not much point in arguing over a patch that no one has even submitted ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Compiler warning with 'fast' variable
Any idea why I am seeing this warning with the new pg_start_backup() 'fast' flag? xlog.c:6917: warning: variable `fast' might be clobbered by `longjmp' or `vfork' The line is in a PG_ENSURE_ERROR_CLEANUP() block. This is with gcc version 2.95.3. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A renewed plea for inclusion of zone.tab
David Fetter da...@fetter.org writes: On Mon, Apr 06, 2009 at 08:48:55PM -0400, Tom Lane wrote: I still see no point in this unless we expose the information in pg_timezone_names, which requires rather more than a one-line patch. There's really no point, and a lot of good stuff lost, Like what? I do not actually believe that anyone needs an interactive geographical timezone selector based on pg_timezone_names. Any such application is far more likely to be looking at the system tzdata files. In any case it would need a lot more data that we aren't supplying (like, say, a world map...) My fundamental objection here is that we'd be permanently widening the API we have to support for timezones, which could come back to haunt us. I will agree that it's not too likely upstream would stop supporting zone.tab entirely, but it's quite likely they could change the format or further complicate its relationship to the actual zone list. I don't wish to buy into that without a more credible argument that there are actual database applications that need this data. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A renewed plea for inclusion of zone.tab
On Apr 7, 2009, at 3:26 PM, Alvaro Herrera wrote: Agreed, it seems to me that a patch to install zone.tab during make install could be applied at this time (before beta so that packagers don't complain that we didn't give them time to fix their file lists). A more complete patch can be discussed for 8.5. ... though there's not much point in arguing over a patch that no one has even submitted ... Andrew did, in fact, submit the patch to install zone.tab. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Compiler warning with 'fast' variable
Bruce Momjian br...@momjian.us writes: Any idea why I am seeing this warning with the new pg_start_backup() 'fast' flag? xlog.c:6917: warning: variable `fast' might be clobbered by `longjmp' or `vfork' The line is in a PG_ENSURE_ERROR_CLEANUP() block. This is with gcc version 2.95.3. That's pretty bizarre --- I don't see it here with gcc 2.95.3, and there is no reason for such a warning to appear on a variable that isn't changed during the function. We could stick a volatile on it but I'd like to find out why this particular variable seems to need that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Array types
On Apr 7, 2009, at 12:54 PM, John Lister wrote: Cheers, nice to know it is possible... Now to see if i can get java/ python to do the same :) or to use a modified libpq somehow... http://python.projects.postgresql.org will do it for Python. =D tho, only supports Python 3, which is still quite new. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Compiler warning with 'fast' variable
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Any idea why I am seeing this warning with the new pg_start_backup() 'fast' flag? xlog.c:6917: warning: variable `fast' might be clobbered by `longjmp' or `vfork' The line is in a PG_ENSURE_ERROR_CLEANUP() block. This is with gcc version 2.95.3. That's pretty bizarre --- I don't see it here with gcc 2.95.3, and there is no reason for such a warning to appear on a variable that isn't changed during the function. We could stick a volatile on it but I'd like to find out why this particular variable seems to need that. You ready for this; changing 'bool' to 'int' supressed the warning: int fast = PG_GETARG_BOOL(1); Using 'char' returns the warning. Changing the assignment to 'true' also fixes it: boolfast = true; This also generates no warning about longjmp: boolfast = PG_GETARG_TEXT(1); No warning here either: boolfast = (bool) PG_GETARG_DATUM(0); This generates the warning: boolfast = ((bool) ((bool) (PG_GETARG_DATUM(1)) != 0)); This does not: boolfast = (bool) (PG_GETARG_DATUM(1) != 0); -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Compiler warning with 'fast' variable
Bruce Momjian br...@momjian.us writes: Tom Lane wrote: We could stick a volatile on it but I'd like to find out why this particular variable seems to need that. You ready for this; changing 'bool' to 'int' supressed the warning: int fast = PG_GETARG_BOOL(1); Well, that's a compiler bug :-(. Probably platform-specific, too, which is why I don't see it on HPPA. I think that the above variant is the least ugly of the alternatives you show as working, and definitely less ugly than plastering volatile on it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Compiler warning with 'fast' variable
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Tom Lane wrote: We could stick a volatile on it but I'd like to find out why this particular variable seems to need that. You ready for this; changing 'bool' to 'int' supressed the warning: int fast = PG_GETARG_BOOL(1); Well, that's a compiler bug :-(. Probably platform-specific, too, which is why I don't see it on HPPA. I think that the above variant is the least ugly of the alternatives you show as working, and definitely less ugly than plastering volatile on it. Well, let's leave it alone and see if anyone else find it; I can mask it on my end. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A renewed plea for inclusion of zone.tab
David E. Wheeler wrote: On Apr 7, 2009, at 3:26 PM, Alvaro Herrera wrote: Agreed, it seems to me that a patch to install zone.tab during make install could be applied at this time (before beta so that packagers don't complain that we didn't give them time to fix their file lists). A more complete patch can be discussed for 8.5. ... though there's not much point in arguing over a patch that no one has even submitted ... Andrew did, in fact, submit the patch to install zone.tab. Hmm, yeah, that he did. (Seems to be missing make uninstall support though.) -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A renewed plea for inclusion of zone.tab
Alvaro == Alvaro Herrera alvhe...@commandprompt.com writes: Andrew did, in fact, submit the patch to install zone.tab. Alvaro Hmm, yeah, that he did. (Seems to be missing make Alvaro uninstall support though.) The rm -rf in the uninstall rule seems to be sufficient for that. (What _is_ missing, as I said, is Windows support.) -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A renewed plea for inclusion of zone.tab
Tom == Tom Lane t...@sss.pgh.pa.us writes: David Fetter da...@fetter.org writes: On Mon, Apr 06, 2009 at 08:48:55PM -0400, Tom Lane wrote: I still see no point in this unless we expose the information in pg_timezone_names, which requires rather more than a one-line patch. There's really no point, and a lot of good stuff lost, Tom Like what? I do not actually believe that anyone needs an Tom interactive geographical timezone selector based on Tom pg_timezone_names. As the bard said, There are more things in heaven and earth, Horatio, than are dreamed of in your philosophy. Having been involved in writing an app that would have used exactly such a thing had it been available, I find your disbelief somewhat ... unpersuasive. The frequency with which the topic comes up on IRC is also significant (it's not a multiple-times-per-week thing like window functions or LATERAL, but it's often enough to be noticed). The usual conversation goes something like this (generally following on from some discussion of how to do timezone conversions): Q: how do I get the list of available zone names? A: see pg_timezone_names Q: but there's 1650/1400/560/452 [delete as applicable] entries in there! how do I know which one to use for any given user? Can I work it out from the user's location? A: Some locations have timezones that vary by county level, so it's hard to automate unless you have a street address and detailed maps/database of Indiana and other awkward places. Best bet is to ask the user themselves, once you know what country they're in. Q: How do you know what zones are in what countries? A: that info is in zone.tab, which you can find either from your OS's timezone directory or from the postgres source for your postgres version. Put that data in a table or something and use it to prompt the user; it has text to help disambiguate the obscure cases. Q: ... wtf? why is that not installed anywhere? Tom Any such application is far more likely to be looking at the Tom system tzdata files. Only if it's using the system TZ functions to do conversions rather than doing them inside pg, which certainly isn't how _I'd_ recommend an app writer do it. Tom In any case it would need a lot more data that we aren't Tom supplying (like, say, a world map...) Nope. While I'm sure someone has a use for the lat/long stuff, the more likely approach is just to select the zone names and explanatory text for the country of interest, and let the user select a zone. No extra data needed. Tom My fundamental objection here is that we'd be permanently Tom widening the API we have to support for timezones, which could Tom come back to haunt us. I will agree that it's not too likely Tom upstream would stop supporting zone.tab entirely, but it's quite Tom likely they could change the format or further complicate its Tom relationship to the actual zone list. I don't wish to buy into Tom that without a more credible argument that there are actual Tom database applications that need this data. zone.tab doesn't become part of the API any more than the actual content of timezone/America/New_York is part of the API. It is up to whoever is providing an interface to access that data to cope with any changes in format. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] More message encoding woes
Tom Lane wrote: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Hiroshi Inoue wrote: What is wrong with checking if the codeset is valid using iconv_open()? That would probably work as well. We'd have to decide what we'd try to convert from with iconv_open(). The problem I have with that is that you are now guessing at *two* platform-specific encoding names not one, plus hoping there is a conversion between the two. AFAIK iconv_open() supports all combinations of the valid encoding values. Or we may be able to check it using the same encoding for both from and to. regards, Hiroshi Inoue -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] a few crazy ideas about hash joins
On 2009-04-03, Simon Riggs si...@2ndquadrant.com wrote: On Fri, 2009-04-03 at 18:03 +0100, Greg Stark wrote: I wonder if we need a whole class of index algorithms to deal specifically with read-only tables I think we can drop the word index from the sentence as well. Read-only isn't an isolated case. Often you find many read-only tables alongside rapidly changing tables. So even the busiest of databases can benefit from read-only optimisations. So I want MVCC *and* read only, not MVCC everywhere (or MVCC nowhere if customer changes horses to get read-only benefits elsewhere). Having changes to those tables cause much heavier additional work is OK, if judged on a cost/benefit basis. So the case I care about ought to be called read-mostly but we're talking write:read ratios of millions:1. For the record and in case anyone gets interested in following up the idea of read only tables, see also: http://thread.gmane.org/gmane.comp.db.postgresql.devel.general/76366 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] another tiny fix (tab-completion) for \ef in psql
While answering a question about something else, I spotted another omission regarding \ef - no tab-completion for it. This is the trivial patch, not sure if there's any benefit in trying to be more specific. -- Andrew (irc:RhodiumToad) Index: src/bin/psql/tab-complete.c === RCS file: /projects/cvsroot/pgsql/src/bin/psql/tab-complete.c,v retrieving revision 1.182 diff -c -r1.182 tab-complete.c *** src/bin/psql/tab-complete.c 6 Apr 2009 15:50:59 - 1.182 --- src/bin/psql/tab-complete.c 8 Apr 2009 01:38:47 - *** *** 2218,2223 --- 2218,2226 else if (strncmp(prev_wd, \\d, strlen(\\d)) == 0) COMPLETE_WITH_SCHEMA_QUERY(Query_for_list_of_tisv, NULL); + else if (strcmp(prev_wd, \\ef) == 0) + COMPLETE_WITH_SCHEMA_QUERY(Query_for_list_of_functions, NULL); + else if (strcmp(prev_wd, \\encoding) == 0) COMPLETE_WITH_QUERY(Query_for_list_of_encodings); else if (strcmp(prev_wd, \\h) == 0 || strcmp(prev_wd, \\help) == 0) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] another tiny fix (tab-completion) for \ef in psql
Andrew == Andrew Gierth and...@tao11.riddles.org.uk writes: Andrew While answering a question about something else, I spotted Andrew another omission regarding \ef - no tab-completion for it. Andrew This is the trivial patch, not sure if there's any benefit in Andrew trying to be more specific. I missed a bit there - it should probably be in backslash_commands too. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Auto-delete large objects when referencing row is deleted
Hi I assume you mean $subject and not what you wrote here. Yes. Sorry it's my mistake. I examined contrib/lo which offers this functionality. Yes. I wonder why the TODO item is there at all, when contrib/lo already solves it in a perfectly reasonable way. As a user of database, I think contrib/lo is not the best way. Because it's not a part of core PostgreSQL, users may forget to use them. Or it is a little messy to use. So I think we need to implement *Auto* delete functionality in PostgreSQL core. Cheers. - Taro Minowa(Higepon) Cybozu Labs, Inc. http://www.monaos.org/ http://code.google.com/p/mosh-scheme/ On Mon, Apr 6, 2009 at 11:06 PM, Tom Lane t...@sss.pgh.pa.us wrote: higepon hige...@gmail.com writes: I found a TODO item pg_dump Add dumping of comments on index columns for large objects. and want to write a patch for it. I assume you mean $subject and not what you wrote here. I examined contrib/lo which offers this functionality. Yes. I wonder why the TODO item is there at all, when contrib/lo already solves it in a perfectly reasonable way. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Solution of the file name problem of copy on windows.
Hi, Hiroshi Saito z-sa...@guitar.ocn.ne.jp wrote: At this time, a copy file name is UTF-8. It was troubled by handling.:-( Then, I make this proposal patch. I think the problem is not only in Windows but also in all platforms where the database encoding doesn't match their OS's encoding. Instead of Windows specific codes, how about adding GetPlatformEncoding() and convert all of *absolute* paths? It would be performed at the lowest API layer; i.e, BasicOpenFile(). Standard database file accesses with RelFileNode are not affected because is uses *relative* paths. There are some issues: * Is it possible to determine the platform encoding? * The above cannot handle non-ascii path under $PGDATA. Is it acceptable? * In Windows, the native encoding is UTF-16, but we will use SJIS if we take on the above method. Is the limitation acceptable? Comments welcome. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Closing some 8.4 open items
On Mon, Apr 06, 2009 at 10:51:22PM -0700, David Fetter wrote:
On Sun, Apr 05, 2009 at 05:57:46PM -0700, David Fetter wrote:
On Sun, Apr 05, 2009 at 08:55:07PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:
The \df thing? That's something it'd be okay to revisit during
beta, IMHO.
OK, I'll work on this tomorrow :)
I think what we were lacking was consensus on what it should do, not
code ...
I was thinking I'd knock out a proposal or two.
Please find enclosed one way to handle it, this being prepending
WINDOW to the result types in \df.
Another way, patch coming tomorrow, would be to add a \dw and remove
the functions where pg_proc.iswindowing is true from \df.
Here's another way, adding \dw.
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index b39466d..626eadc 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -396,6 +396,9 @@ exec_command(const char *cmd,
case 'u':
success = describeRoles(pattern, show_verbose);
break;
+ case 'w':
+ success = describeWindowingFunctions(pattern,
show_system);
+ break;
case 'F': /* text search
subsystem */
switch (cmd[2])
{
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index cc88984..c718267 100644
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -286,6 +286,9 @@ describeFunctions(const char *pattern, bool verbose, bool
showSystem)
appendPQExpBuffer(buf, AND n.nspname 'pg_catalog'\n
AND
n.nspname 'information_schema'\n);
+if (pset.sversion = 80400)
+ appendPQExpBuffer(buf, AND NOT p.proiswindow\n);
+
processSQLNamePattern(pset.db, buf, pattern, true, false,
n.nspname, p.proname,
NULL,
pg_catalog.pg_function_is_visible(p.oid));
@@ -3069,6 +3072,60 @@ listUserMappings(const char *pattern, bool verbose)
return true;
}
+bool
+describeWindowingFunctions(const char *pattern, bool showSystem)
+{
+ PQExpBufferData buf;
+ PGresult *res;
+ printQueryOpt myopt = pset.popt;
+
+ if (pset.sversion 80400)
+ {
+ fprintf(stderr, _(The server (version %d.%d) does not support
windowing functions.\n),
+ pset.sversion / 1, (pset.sversion / 100) %
100);
+ return true;
+ }
+
+ initPQExpBuffer(buf);
+
+ printfPQExpBuffer(buf,
+ SELECT n.nspname as \%s\,\n
+ p.proname as \%s\,\n
+
pg_catalog.pg_get_function_result(p.oid) as \%s\,\n
+
pg_catalog.pg_get_function_arguments(p.oid) as \%s\
+ \nFROM pg_catalog.pg_proc p
+ \n LEFT JOIN
pg_catalog.pg_namespace n ON n.oid = p.pronamespace\n
+ WHERE p.proiswindow\n,
+ gettext_noop(Schema),
+ gettext_noop(Name),
+ gettext_noop(Result data type),
+ gettext_noop(Argument data types));
+
+ if (!showSystem !pattern)
+ appendPQExpBuffer(buf, AND n.nspname 'pg_catalog'\n
+ AND
n.nspname 'information_schema'\n);
+
+ processSQLNamePattern(pset.db, buf, pattern, true, false,
+ n.nspname, p.proname,
NULL,
+
pg_catalog.pg_function_is_visible(p.oid));
+
+ appendPQExpBuffer(buf, ORDER BY 1, 2, 4;);
+
+ res = PSQLexec(buf.data, false);
+ termPQExpBuffer(buf);
+ if (!res)
+ return false;
+
+ myopt.nullPrint = NULL;
+ myopt.title = _(List of windowing functions);
+ myopt.translate_header = true;
+
+ printQuery(res, myopt, pset.queryFout, pset.logfile);
+
+ PQclear(res);
+ return true;
+}
+
/*
* printACLColumn
*
diff --git a/src/bin/psql/describe.h b/src/bin/psql/describe.h
index
Re: [HACKERS] Closing some 8.4 open items
Tom, finishing posix_fadvise patch Push to TODO So has fadvise been completely dropped from 8.4, or only partially? change psql's \df output for window functions? Drop; there's no consensus that this should be changed Also, Fetter is currently working on a \dw for 8.5. Polymorphic types vs. domains Push to TODO Agreed. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] a few crazy ideas about hash joins
On Tue, Apr 7, 2009 at 5:57 PM, Bruce Momjian br...@momjian.us wrote: I think perhaps Optimizer / Executor would be more appropriate, since these are not about hash indices but rather about hash joins. I will look at doing that. Yes, please. Done. See what you think... Also I think the last item under Index / Hash is actually NOT done, and belongs in the main index section rather than Index / Hash. Yep, I didn't realize that editing Index also does the subsections, while editing the subsections doesn't edit the upper level. Heh. I'd write some webapps to do some of these things, but I haven't been able to interest anyone in providing me with a postgresql.org-based hosting arrangement. The first item in the Index / Hash section doesn't really look like a TODO, or at the very least it's unclear what the action item is supposed to be. Yep, remove, thanks. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Closing some 8.4 open items
On Tue, Apr 7, 2009 at 10:42 PM, Josh Berkus j...@agliodbs.com wrote: Tom, finishing posix_fadvise patch Push to TODO So has fadvise been completely dropped from 8.4, or only partially? Bitmap scans will support it, but index scans will not. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Array types
On Tue, Apr 7, 2009 at 6:42 PM, James Pye li...@jwp.name wrote: On Apr 7, 2009, at 12:54 PM, John Lister wrote: Cheers, nice to know it is possible... Now to see if i can get java/python to do the same :) or to use a modified libpq somehow... http://python.projects.postgresql.org will do it for Python. =D tho, only supports Python 3, which is still quite new. I took a quick look at the pg python driver and was very impressed. They implemented a full top to bottom binary driver with type i/o functions in the vein of libpqtypes. If you are writing python, this is definitely the way to go. Kudos to them for seeing the light and doing it that way...it's much better coupling with the server than marshaling everything through text. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] another tiny fix (tab-completion) for \ef in psql
Andrew Gierth wrote: Andrew == Andrew Gierth and...@tao11.riddles.org.uk writes: Andrew While answering a question about something else, I spotted Andrew another omission regarding \ef - no tab-completion for it. Andrew This is the trivial patch, not sure if there's any benefit in Andrew trying to be more specific. I missed a bit there - it should probably be in backslash_commands too. OK, patch applied and I added it to backslash_commands too. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Auto-delete large objects when referencing row is deleted
higepon hige...@gmail.com wrote: As a user of database, I think contrib/lo is not the best way. Because it's not a part of core PostgreSQL, users may forget to use them. Or it is a little messy to use. So I think we need to implement *Auto* delete functionality in PostgreSQL core. (It would be a rare case, but) A large object might be referenced by two or more rows because LO interface is split into two steps; allocating oid and storing data for it. The oid could be stored in two or more places and auto deletion would break such usecases. BTW, bytea and TOASTing would works perfectly as you expected. Why don't you use bytea instead of large objects? In other words, what you want actually is not LO improvement but efficient TOASTing, no? Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Closing some 8.4 open items
Robert Haas robertmh...@gmail.com writes: On Tue, Apr 7, 2009 at 10:42 PM, Josh Berkus j...@agliodbs.com wrote: So has fadvise been completely dropped from 8.4, or only partially? Bitmap scans will support it, but index scans will not. And please note that we think bitmap scans are the larger part of the win anyway. What's left undone there is some marginal mopup. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Closing some 8.4 open items
On Tue, Apr 07, 2009 at 07:42:51PM -0700, Josh Berkus wrote: Tom, finishing posix_fadvise patch Push to TODO So has fadvise been completely dropped from 8.4, or only partially? change psql's \df output for window functions? Drop; there's no consensus that this should be changed Also, Fetter is currently working on a \dw for 8.5. I sent it, targeted for 8.4 :) Windowing functions are new in 8.4, so I'm thinking it should go into the front-end tools, too. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
