[HACKERS] Bug with PATHs having non-ASCII characters
Just an FYI regarding this bug: http://archives.postgresql.org/pgsql-bugs/2009-12/msg00267.php Windows always uses UNICODE to store file and directory names. The wide-char version of any WIN32 API call will accept or return data in UTF-16 encoded Unicode, regardless of the local environment's single-byte (MBCS) encoding settings (codepage). So in the windows environment, at least, you can always be sure how to handle file/directory/path that includes non-ASCII characters. It's a little bit of a pain to use the wide-char API calls from PostgreSQL, but converting UTF-16 from and to UTF-8 is pretty easy and a guaranteed 1:1 mapping. P.s. The non-wide-char version of the Win32 API is just a bunch of wrappers that convert the char data to/from UTF-16 based on the current codepage. The wide-char API is the native one. To force the call to the wide-char API version, you just add W to the end of the function name (adding A forces it the other way). -- 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] Block-level CRC checks
A curiosity question regarding torn pages: How does this work on file systems that don't write in-place, but instead always do copy-on-write? My example would be Sun's ZFS file system (In Solaris & BSD). Because of its "snapshot & rollback" functionality, it never writes a page in-place, but instead always copies it to another place on disk. How does this affect the corruption caused by a torn write? Can we end up with horrible corruption on this type of filesystem where we wouldn't on normal file systems, where we are writing to a previously zeroed area on disk? Sorry if this is a stupid question... Hopefully somebody can reassure me that this isn't an issue. -- 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] UTF8 with BOM support in psql
> -Original Message- > From: Andrew Dunstan [mailto:and...@dunslane.net] > Sent: Tuesday, November 17, 2009 9:15 AM > To: Peter Eisentraut > Cc: Chuck McDevitt; Itagaki Takahiro; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] UTF8 with BOM support in psql > > > > Peter Eisentraut wrote: > > On tis, 2009-11-17 at 00:59 -0800, Chuck McDevitt wrote: > > > >> Or is there a plan to read and convert the UTF-16 or UTF-32 to UTF-8, > >> so psql and PostgreSQL understand it? > >> (BTW, that would actually be nice on Windows, where UTF-16 is > common). > >> > > > > Well, someone could implement UTF-16 or UTF-whatever as client > encoding. > > But I have not heard of any concrete proposals about that. > > > > > > Doesn't the nul byte problem make that seriously hard? > Not really... You can't treat UTF-16 the same way you do UTF-8, but we are talking about it being a client_encoding, not a server_encoding. So, it's only the routines that look at the strings pre-conversion, and the conversion routines themselves, that need to understand UTF-16 strings are 16-bits at a time, and end with a 16 bit 0x. Obviously, it's more work than handing another 8-bit client_encoding, but doesn't seem insurmountable. And given the 1:1 mapping from UTF-16 to UTF-8, you don't have any new issues due to characters that can't be converted. -- 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] UTF8 with BOM support in psql
> -Original Message- > From: Peter Eisentraut [mailto:pete...@gmx.net] > Sent: Tuesday, November 17, 2009 9:05 AM > To: Chuck McDevitt > Cc: Itagaki Takahiro; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] UTF8 with BOM support in psql > > On tis, 2009-11-17 at 00:59 -0800, Chuck McDevitt wrote: > > Or is there a plan to read and convert the UTF-16 or UTF-32 to UTF-8, > > so psql and PostgreSQL understand it? > > (BTW, that would actually be nice on Windows, where UTF-16 is common). > > Well, someone could implement UTF-16 or UTF-whatever as client encoding. > But I have not heard of any concrete proposals about that. Certainly that would be nice, given that UTF-16 is the "native" encoding for Java, C#, Visual Basic.net, JDBC, ODBC drivers >= ver 3.5, Microsoft Windows (all system calls use UTF-16, with a compatibility layer for old apps), and apps that Postgres users might switch from, such as MS SQLServer. But for the short term, a warning or error saying we don't support it is better than a confusing lexer error or syntax error. -- 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] UTF8 with BOM support in psql
> > I don't know what the best solution is here. The BOM encoded as UTF-8 > is valid data in other encodings. Of course, there is your point that > such data cannot be at the start of an SQL command. > Is the UTF-8 BOM ( EF BB BF ) actually valid data in any other multi-byte encoding (other than it's intended use in UTF-8)? I realize that for single-byte encoding, such as latin-1, it would be legal as data, since any bytes other that 00 are legal, although never legal outside a quoted string in a SQL command or psql command. Certainly, no psql command input file can start with those bytes, or you would get an error (unless it is changed so the BOM is ignored). As to zero-width non-breaking space: the BOM is supposed to be treated as such if in the middle of a string, but if it is the start, it is just the BOM, and isn't considered part of the data, if I'm reading the spec right. Perhaps the lexers should allow for it as white space (along with other Unicode space characters, such as U+2060). It's not really important, since allowing the BOM sequence in the middle of a file is "deprecated" according to the Unicode standard. And what if you see a real BOM, FF FE or FE FF or FF FE 00 00 or 00 00 FE FF? Give an error saying UTF-16 and UTF-32 are not supported? Or is there a plan to read and convert the UTF-16 or UTF-32 to UTF-8, so psql and PostgreSQL understand it? (BTW, that would actually be nice on Windows, where UTF-16 is common). If we accept UTF-8 BOM, we should at least detect the other BOM sequences and give an error or warning. Overall, from my user point of view, having psql deal with the BOM (at least the utf-8 one) would be more friendly than current behavior, as some editors (notepad for example) automatically add the BOM to the beginning of Unicode files, and it's not obvious without dumping the file in hex. -- 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] Upgrading our minimum required flex version for 8.5
> -Original Message- > From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers- > ow...@postgresql.org] On Behalf Of Tom Lane > Sent: Monday, July 13, 2009 7:43 PM > To: Andrew Dunstan > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Upgrading our minimum required flex version for > 8.5 > > Andrew Dunstan writes: > > Well, it looks like there's a reason GnuWin32 hasn't advanced beyond > > 2.5.4a - after that the flex developers proceeded to make flex use a > > filter chain methodology that requires the use of fork(). Making it > run > > on Windows without the support of Msys or Cygwin would involve some > > significant surgery, I suspect. > > Egad, this is a mess :-(. I noticed in the flex changelog that they'd > switched to using m4 instead of implementing all the text processing > themselves. I suppose this is a consequence of that. > > But I'm not prepared to agree that M$ lameness should restrict us to > using only a 1990s version of flex. Didn't somebody mention upthread > that there is a Windows port of 2.5.33 available? > > > Maybe for the time being we need to think about keeping scan.c in > CVS. > > It's not like scan.l gets updated all that often. > > We could if we had to, though it amounts to saying that Windows-based > developers don't get to touch the scanner. > > regards, tom lane Flex 2.5.33 and bison 2.3 are available from mingw for windows. http://sourceforge.net/projects/mingw/files/ Since mingw programs don't need Cygwin installed, these should probably be OK for most Windows people. But if really needed, flex 2.5.33 could be ported (m4 is already ported). I'm also wonderings why flex is a problem, since there is a GNUwin32 (native) port of Bison 2.4.1 and m4, And Bison uses m4 these days, doesn't it? Perhaps it wouldn't be so hard to update flex to use the same m4 calling that bison uses? Chuck McDevitt -- 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] [PATCH] backend: compare word-at-a-time in bcTruelen
> -Original Message- > From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers- > ow...@postgresql.org] On Behalf Of Stephen Frost > Sent: Tuesday, June 16, 2009 5:47 AM > To: Greg Stark > Cc: Robert Haas; Jeremy Kerr; ; Alvaro > Herrera; Stefan Kaltenbrunner; Gurjeet Singh > Subject: Re: [HACKERS] [PATCH] backend: compare word-at-a-time in > bcTruelen > On 64-bit machines, the native word size is 64-bits (obviously), and comparing 32 bits at a time is much slower than comparing 64 bits at a time. You might want to consider this. -- 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] Multiple sorts in a query
> -Original Message- > From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers- > ow...@postgresql.org] On Behalf Of Simon Riggs > Sent: Tuesday, May 19, 2009 4:32 AM > To: pgsql-hackers > Subject: [HACKERS] Multiple sorts in a query > > > Just wanted to check some thoughts about how memory allocation works in > complex queries. Been thinking some more about recent Solaris testing > results that *seemed* to show issues with multiple concurrent queries > that have multiple sorts. > > If we have a query that uses multiple sorts, we may have a top-level > sort, with child nodes that contain sorts also. In some cases we may > find with sub-nodes that have both inner and outer sub-trees that > contain sorts also. > > If we allocate large chunks of memory we use malloc(). So complex > queries can have multiple mallocs, followed by multiple reallocs. That > in itself seems likely to end up with roughly double memory use, since > realloc won't work properly/quickly with multiple mallocs. (Double > since > we allocate X bytes, then 2X bytes etc until we hit the limit.) > > When we later free() the memory, do we always free() it in the reverse > order in which it was allocated? If not, how does that effect reducing > the sbrk point, or other aspects of reusing allocated memory? > > Is it possible that Solaris's default malloc isn't appropriate for > repeated use in complex queries that use multiple sorts? > http://developers.sun.com/solaris/articles/multiproc/multiproc.html > and recent OpenSolaris bug reports. Solaris default malloc always uses sbrk(), and never ever tried to reduce the sbrk point. If you want a malloc that uses mmap, there is an non-default malloc that does that (libumem or something?) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] UHC as a server encoding?
Why are certain character encodings not legal for the server_encoding? For example, we allow EUC_KR, but disallow UHC, which is a superset of EUC_KR. What are the rules for what is or is not allowed as server_encoding? Is it having a conversion to MIC that is the issue? Why is that important for server encodings? -- 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] Solaris getopt_long and PostgreSQL
Perhaps I could use the same test pg_status uses to decide PS_USE_CHANGE_ARGV and PS_USE_CLOBBER_ARGV? Any obviously, we don't just use ours for platforms with no or broken getopt_long, since we are talking Solaris (which has a bug in getopt, but getopt_long works fine) > -Original Message- > From: Tom Lane [mailto:t...@sss.pgh.pa.us] > Sent: Tuesday, March 17, 2009 11:26 AM > To: Chuck McDevitt > Cc: Zdenek Kotala; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Solaris getopt_long and PostgreSQL > > Chuck McDevitt writes: > > This is because MAC, BSD and GNU getopt_long permutes the arguments, > and our getopt_long does not. > > AFAIK those all work by scribbling on the original argv[] array, a > behavior that seems pretty risky from a portability standpoint. > Since our port/ module is only going to get used on old platforms with > no or broken getopt_long(), it needs to be pretty conservative about > what it assumes the system environment can handle. > > 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] Solaris getopt_long and PostgreSQL
What about the idea of updating our getopt and getopt_long to a more modern version by porting over netBSD getopt? The current situation is confusing for users, as "psql databasename -p port" type of calls works on almost all platforms, but not on those using the internal getopt/getopt_long. For those, you get "-p" is not a valid user. This is because MAC, BSD and GNU getopt_long permutes the arguments, and our getopt_long does not. > -Original Message- > From: Tom Lane [mailto:t...@sss.pgh.pa.us] > Sent: Tuesday, March 17, 2009 11:02 AM > To: Zdenek Kotala > Cc: Chuck McDevitt; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Solaris getopt_long and PostgreSQL > > Zdenek Kotala writes: > > [ use Solaris' version of getopt_long ] > > The reason not to do that was discussed in this thread: > > http://archives.postgresql.org//pgsql-patches/2008-02/msg00075.php > > While Chuck is certainly free to build his local copy however he wants, > I don't think we're going to revert this change in the community > sources. > > 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
[HACKERS] Solaris getopt_long and PostgreSQL
About a year ago, you talked to the PostgreSQL people about some problem with Solaris getopt_long, and they changed the build to use the internal getopt_long instead of the Solaris one? What was the problem with Solaris getopt_long? Does the problem still exist in Solaris 10? My users are unhappy at the change, since normal getopt_long reorders the args, and apparently the built-in one doesn't, so "psql database -p port" no longer works, since it treats -p as the user name. I don't know if I should revert that change, or port netBSD getopt_long and replace the PostgreSQL one with that.
Re: [HACKERS] Optimizing COPY
What if the block of text is split in the middle of a multibyte character? I don't think it is safe to assume raw blocks always end on a character boundary. -- 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] Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle
Doesn't ANSI standard interval syntax have the minus sign before the quotes? Select interval -'2008-10'; ??? > -Original Message- > From: [EMAIL PROTECTED] [mailto:pgsql-hackers- > [EMAIL PROTECTED] On Behalf Of Tom Lane > Sent: Saturday, November 08, 2008 11:39 AM > To: Ron Mayer > Cc: Brendan Jurd; Kevin Grittner; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Patch for SQL-Standard Interval output and > decoupling DateStyle from IntervalStyle > > BTW, I just noticed that CVS HEAD has a bug in reading negative SQL- > spec > literals: > > regression=# select interval '-2008-10'; >interval > -- > -2008 years -10 mons > (1 row) > > regression=# select interval '--10'; > interval > -- > 10 mons > (1 row) > > Surely the latter must mean -10 months. This is orthogonal to the > current patch ... > > 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 -- 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] Multi CPU Queries - Feedback and/or suggestions wanted!
There is a problem trying to make Postgres do these things in Parallel. The backend code isn't thread-safe, so doing a multi-thread implementation requires quite a bit of work. Using multiple processes has its own problems: The whole way locking works equates one process with one transaction (The proc table is one entry per process). Processes would conflict on locks, deadlocking themselves, as well as many other problems. It's all a good idea, but the work is probably far more than you expect. Async I/O might be easier, if you used pThreads, which is mostly portable, but not to all platforms. (Yes, they do work on Windows) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Baker Sent: 2008-10-20 22:25 To: Julius Stroffek Cc: pgsql-hackers@postgresql.org; Dano Vojtek Subject: Re: [HACKERS] Multi CPU Queries - Feedback and/or suggestions wanted! On Mon, Oct 20, 2008 at 12:05 PM, Julius Stroffek <[EMAIL PROTECTED]> wrote: Topics that seem to be of interest and most of them were already discussed at developers meeting in Ottawa are 1.) parallel sorts 2.) parallel query execution 3.) asynchronous I/O 4.) parallel COPY 5.) parallel pg_dump 6.) using threads for parallel processing [...] 2.) Different subtrees (or nodes) of the plan could be executed in parallel on different CPUs and the results of this subtrees could be requested either synchronously or asynchronously. I don't see why multiple CPUs can't work on the same node of a plan. For instance, consider a node involving a scan with an expensive condition, like UTF-8 string length. If you have four CPUs you can bring to bear, each CPU could take every fourth page, computing the expensive condition for each tuple in that page. The results of the scan can be retired asynchronously to the next node above. -jwb
Re: [HACKERS] IDE
If you are talking about working on the code (internals), I find eclipse works very well for working on PostgreSQL. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pedro Belmino Sent: Monday, October 01, 2007 6:42 AM To: pgsql-hackers@postgresql.org Subject: [HACKERS] IDE Hello, I am having problems of productivity with IDE that I am using. Exists some IDE that recommended to develop postgresql? I am thankful, -- Pedro Belmino.
Re: [HACKERS] Suggestion for MSVC build
> > > > Many of us would like to see libedit ported to Windows too ;-) > > Yeah, it's on my (insanely long) TODO to look at sometime :-) > > //Magnus I've thought about working on a libedit port myself, but I don't see how that would help PostgreSQL unless the PostgreSQL community would be willing to include the libedit code into our source tree (pgsql/src/port/? ). Otherwise it would just be downloadable from some obscure place that most people won't find or trust. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Suggestion for MSVC build
The .def files can be generated from cygwin or mingw's dlltool command: erase readline.def erase history.def dlltool --export-all-symbols -z readline.def libreadline.a dlltool --export-all-symbols -z history.def libhistory.a lib /machine:i386 /def:readline.def lib /machine:i386 /def:history.def (note: dlltool won't overwrite a def file if it exists). But why would this be necessary? It looks like the readline distribution is broken. > -Original Message- > From: Chuck McDevitt > Sent: Monday, September 24, 2007 11:59 PM > To: 'Magnus Hagander' > Cc: 'pgsql-hackers@postgresql.org' > Subject: RE: [HACKERS] Suggestion for MSVC build > > Actually, the more I look at it, I realize it was correct before > > We want to link against readline.lib and history.lib, but the ones in > the GnuWin32 distribution are broken. > The .lib files are made from the .def files, which are supposed to list > the exports, but don't. > > They can be made from commands like this: > > lib /machine:i386 /def:readline.def > lib /machine:i386 /def:history.def > > But that only works if the .def files list the routines you want > exported. > > It's easy enough to add the few we use by hand, but I'm not sure why > they aren't there. > Adding them, running those lib commands, allowed me to link with no > errors or warnings. > > Maybe I need to do some research on readline... this seems more > complicated than I expected. > Does no one else use readline on Windows? Is the Gnuwin32 readline a > fraud? I just don't know. > ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Suggestion for MSVC build
Actually, the more I look at it, I realize it was correct before
We want to link against readline.lib and history.lib, but the ones in
the GnuWin32 distribution are broken.
The .lib files are made from the .def files, which are supposed to list
the exports, but don't.
They can be made from commands like this:
lib /machine:i386 /def:readline.def
lib /machine:i386 /def:history.def
But that only works if the .def files list the routines you want
exported.
It's easy enough to add the few we use by hand, but I'm not sure why
they aren't there.
Adding them, running those lib commands, allowed me to link with no
errors or warnings.
Maybe I need to do some research on readline... this seems more
complicated than I expected.
Does no one else use readline on Windows? Is the Gnuwin32 readline a
fraud? I just don't know.
> -Original Message-
> From: Chuck McDevitt
> Sent: Monday, September 24, 2007 2:17 PM
> To: Magnus Hagander
> Cc: pgsql-hackers@postgresql.org
> Subject: RE: [HACKERS] Suggestion for MSVC build
>
> The right lib files to link readline are the .a ones...
>
> Like this:
>
> if ($solution->{options}->{readline})
> {
> $psql->AddIncludeDir($solution->{options}->{readline} .
> '\include');
> $psql->AddLibrary($solution->{options}->{readline} .
> '\lib\libreadline.dll.a');
> $psql->AddLibrary($solution->{options}->{readline} .
> '\lib\libhistory.dll.a');
> }
>
\
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] Suggestion for MSVC build
The right lib files to link readline are the .a ones...
Like this:
if ($solution->{options}->{readline})
{
$psql->AddIncludeDir($solution->{options}->{readline} .
'\include');
$psql->AddLibrary($solution->{options}->{readline} .
'\lib\libreadline.dll.a');
$psql->AddLibrary($solution->{options}->{readline} .
'\lib\libhistory.dll.a');
}
For using readline out of the dll. I assume libreadline.a and
libhistory.a instead for static linking.
> -Original Message-
> From: Magnus Hagander [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 24, 2007 1:30 AM
> To: Chuck McDevitt
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Suggestion for MSVC build
>
> What version readline are you using?
>
> I tried with the latest download, and I get about 200 warnings like:
> 1>.\src\bin\psql\tab-complete.c(600) : warning C4013:
> 'completion_matches'
> undef
> ined; assuming extern returning int
> 1>.\src\bin\psql\tab-complete.c(600) : warning C4047: '=' : 'char **'
> differs in
> levels of indirection from 'int'
>
>
> And also, 12 linker errors - pretty much all the readline stuff. A
> quick
> look at the files seem to show that the readline.lib and history.lib
> files
> that ship with gnuwin32 are empty of symbols. The .def files are also
> empty. Are yours different?
>
>
> Also, do you know if this version of readline actually works on non-US
> locales, or if it's still broken there? (I'd test it myself if I could
> just
> build it :-P)
>
> //Magnus
>
> On Sun, Sep 23, 2007 at 10:03:09PM -0400, Chuck McDevitt wrote:
> > It seems like there isn't any good reason the perl scripts for the
> MSVC
> > build don't support readline
> >
> >
> >
> > Readline for windows is available as part of the GnuWin32 project.
> >
> >
> >
> > http://gnuwin32.sourceforge.net/packages/readline.htm
> >
> >
> >
> > It normally installs to "c:\Program Files\GnuWin32"
> >
> >
> >
> > I'd update the scripts myself, but I'm not a PERL programmer.
> >
> > From what I can see, you'd add another line to config.pl for
> readline,
> > and then add some stuff to mkvcbuild.pm for psql to do something
> like:
> >
> >
> >
> > if ($solution->{options}->{readline})
> >
> > {
> >
> >
> > $psql->AddIncludeDir($solution->{options}->{readline} . '\include');
> >
> >
> > $psql->AddLibrary($solution->{options}->{readline} .
> > '\lib\readline.lib');
> >
> >
> > $psql->AddLibrary($solution->{options}->{readline} .
> > '\lib\history.lib');
> >
> > }
> >
> >
> >
> > And something to solution.pm in the part that builds pg_config.h
that
> > looks something like:
> >
> >
> >
> > if ($self->{options}->{readline})
> >
> > {
> >
> > print O "#define
> > HAVE_LIBREADLINE 1\n";
> >
> > print O "#define
> > HAVE_READLINE_READLINE_H 1\n";
> >
> > print O "#define
> > HAVE_READLINE_HISTORY_H 1\n";
> >
> > print O "#define
> > USE_READLINE 1\n";
> >
> > print O "#define
> > USE_READLINE_STATIC 1\n";
> >
> > }
> >
> > (Not sure about the last line).
> >
> >
> >
> > I don't know if this is a good idea, but I would think this would
> make
> > psql more "user-friendly" on windows.
> >
> >
> >
> > Perhaps someone who understands readline and perl better than me
> might
> > want to take this on?
> >
> >
> >
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] Suggestion for MSVC build
Also, I think I told you the wrong file to link to. I think it is the
.a files, not the .lib files.
Let me check on that.
> -Original Message-
> From: Chuck McDevitt
> Sent: Monday, September 24, 2007 10:34 AM
> To: 'Magnus Hagander'
> Cc: pgsql-hackers@postgresql.org
> Subject: RE: [HACKERS] Suggestion for MSVC build
>
> Sorry, completion_matches hasn't existed in readline for a long time.
>
> You need to define:
>
> #define HAVE_RL_COMPLETION_APPEND_CHARACTER 1
> #define HAVE_RL_COMPLETION_MATCHES 1
> #define HAVE_RL_FILENAME_COMPLETION_FUNCTION 1
>
> Just like we do on Linux.
>
>
> > -Original Message-
> > From: Magnus Hagander [mailto:[EMAIL PROTECTED]
> > Sent: Monday, September 24, 2007 1:30 AM
> > To: Chuck McDevitt
> > Cc: pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] Suggestion for MSVC build
> >
> > What version readline are you using?
> >
> > I tried with the latest download, and I get about 200 warnings like:
> > 1>.\src\bin\psql\tab-complete.c(600) : warning C4013:
> > 'completion_matches'
> > undef
> > ined; assuming extern returning int
> > 1>.\src\bin\psql\tab-complete.c(600) : warning C4047: '=' : 'char
**'
> > differs in
> > levels of indirection from 'int'
> >
> >
> > And also, 12 linker errors - pretty much all the readline stuff. A
> > quick
> > look at the files seem to show that the readline.lib and history.lib
> > files
> > that ship with gnuwin32 are empty of symbols. The .def files are
also
> > empty. Are yours different?
> >
> >
> > Also, do you know if this version of readline actually works on non-
> US
> > locales, or if it's still broken there? (I'd test it myself if I
> could
> > just
> > build it :-P)
> >
> > //Magnus
> >
> > On Sun, Sep 23, 2007 at 10:03:09PM -0400, Chuck McDevitt wrote:
> > > It seems like there isn't any good reason the perl scripts for the
> > MSVC
> > > build don't support readline
> > >
> > >
> > >
> > > Readline for windows is available as part of the GnuWin32 project.
> > >
> > >
> > >
> > > http://gnuwin32.sourceforge.net/packages/readline.htm
> > >
> > >
> > >
> > > It normally installs to "c:\Program Files\GnuWin32"
> > >
> > >
> > >
> > > I'd update the scripts myself, but I'm not a PERL programmer.
> > >
> > > From what I can see, you'd add another line to config.pl for
> > readline,
> > > and then add some stuff to mkvcbuild.pm for psql to do something
> > like:
> > >
> > >
> > >
> > > if ($solution->{options}->{readline})
> > >
> > > {
> > >
> > >
> > > $psql->AddIncludeDir($solution->{options}->{readline} .
> '\include');
> > >
> > >
> > > $psql->AddLibrary($solution->{options}->{readline} .
> > > '\lib\readline.lib');
> > >
> > >
> > > $psql->AddLibrary($solution->{options}->{readline} .
> > > '\lib\history.lib');
> > >
> > > }
> > >
> > >
> > >
> > > And something to solution.pm in the part that builds pg_config.h
> that
> > > looks something like:
> > >
> > >
> > >
> > > if ($self->{options}->{readline})
> > >
> > > {
> > >
> > > print O "#define
> > > HAVE_LIBREADLINE 1\n";
> > >
> > > print O "#define
> > > HAVE_READLINE_READLINE_H 1\n";
> > >
> > > print O "#define
> > > HAVE_READLINE_HISTORY_H 1\n";
> > >
> > > print O "#define
> > > USE_READLINE 1\n";
> > >
> > > print O "#define
> > > USE_READLINE_STATIC 1\n";
> > >
> > > }
> > >
> > > (Not sure about the last line).
> > >
> > >
> > >
> > > I don't know if this is a good idea, but I would think this would
> > make
> > > psql more "user-friendly" on windows.
> > >
> > >
> > >
> > > Perhaps someone who understands readline and perl better than me
> > might
> > > want to take this on?
> > >
> > >
> > >
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Suggestion for MSVC build
Sorry, completion_matches hasn't existed in readline for a long time.
You need to define:
#define HAVE_RL_COMPLETION_APPEND_CHARACTER 1
#define HAVE_RL_COMPLETION_MATCHES 1
#define HAVE_RL_FILENAME_COMPLETION_FUNCTION 1
Just like we do on Linux.
> -Original Message-
> From: Magnus Hagander [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 24, 2007 1:30 AM
> To: Chuck McDevitt
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Suggestion for MSVC build
>
> What version readline are you using?
>
> I tried with the latest download, and I get about 200 warnings like:
> 1>.\src\bin\psql\tab-complete.c(600) : warning C4013:
> 'completion_matches'
> undef
> ined; assuming extern returning int
> 1>.\src\bin\psql\tab-complete.c(600) : warning C4047: '=' : 'char **'
> differs in
> levels of indirection from 'int'
>
>
> And also, 12 linker errors - pretty much all the readline stuff. A
> quick
> look at the files seem to show that the readline.lib and history.lib
> files
> that ship with gnuwin32 are empty of symbols. The .def files are also
> empty. Are yours different?
>
>
> Also, do you know if this version of readline actually works on non-US
> locales, or if it's still broken there? (I'd test it myself if I could
> just
> build it :-P)
>
> //Magnus
>
> On Sun, Sep 23, 2007 at 10:03:09PM -0400, Chuck McDevitt wrote:
> > It seems like there isn't any good reason the perl scripts for the
> MSVC
> > build don't support readline
> >
> >
> >
> > Readline for windows is available as part of the GnuWin32 project.
> >
> >
> >
> > http://gnuwin32.sourceforge.net/packages/readline.htm
> >
> >
> >
> > It normally installs to "c:\Program Files\GnuWin32"
> >
> >
> >
> > I'd update the scripts myself, but I'm not a PERL programmer.
> >
> > From what I can see, you'd add another line to config.pl for
> readline,
> > and then add some stuff to mkvcbuild.pm for psql to do something
> like:
> >
> >
> >
> > if ($solution->{options}->{readline})
> >
> > {
> >
> >
> > $psql->AddIncludeDir($solution->{options}->{readline} . '\include');
> >
> >
> > $psql->AddLibrary($solution->{options}->{readline} .
> > '\lib\readline.lib');
> >
> >
> > $psql->AddLibrary($solution->{options}->{readline} .
> > '\lib\history.lib');
> >
> > }
> >
> >
> >
> > And something to solution.pm in the part that builds pg_config.h
that
> > looks something like:
> >
> >
> >
> > if ($self->{options}->{readline})
> >
> > {
> >
> > print O "#define
> > HAVE_LIBREADLINE 1\n";
> >
> > print O "#define
> > HAVE_READLINE_READLINE_H 1\n";
> >
> > print O "#define
> > HAVE_READLINE_HISTORY_H 1\n";
> >
> > print O "#define
> > USE_READLINE 1\n";
> >
> > print O "#define
> > USE_READLINE_STATIC 1\n";
> >
> > }
> >
> > (Not sure about the last line).
> >
> >
> >
> > I don't know if this is a good idea, but I would think this would
> make
> > psql more "user-friendly" on windows.
> >
> >
> >
> > Perhaps someone who understands readline and perl better than me
> might
> > want to take this on?
> >
> >
> >
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] Problem with MSVC install script
Of course it is better not to remove the readonly on all files in the target dir. That's just a workaround I did because it didn't involve changing the perl scripts. I don't know the "right" perl way to change the readonly attribute on a file. If there isn't one, you could have the perl code issue "attrib" commands on the target location for each file it is moving. Better if there is some more "perl" way to do this. > -Original Message- > From: Magnus Hagander [mailto:[EMAIL PROTECTED] > Sent: Monday, September 24, 2007 12:33 AM > To: Chuck McDevitt > Cc: Andrew Dunstan; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Problem with MSVC install script > > Hrrm. I wonder how likely that is, but I can see it's a problem. > > That said, it's probably not a bad idea to fix it anyway - it would > correspond to setting the permissions on a unix install, which we do. > > For the xcopy commansd, it should be easier to just add a /R switch. > But > most files are copied using the internal perl stuff - anybody know if > those > can be made to overwrite readonly files easily? > > Also, do we really want to remove the readonly file on all the files in > the > target dir including subdirs? That may hit a bunch of files that aren't > actualliy "ours". Perhaps we need to process it on a file-by-file > basis? > > //Magnus > > On Mon, Sep 24, 2007 at 02:59:54AM -0400, Chuck McDevitt wrote: > > Well, I was checking out from a different cvs server, and had things > set > > to use CVS EDIT, where everything is read-only by default, until you > > issue a cvs edit command. > > So many files that aren't built by the build system, but just get > copied > > as-is, end up read-only. > > > > But it would be true for any files set read-only. > > > > > -Original Message- > > > From: Andrew Dunstan [mailto:[EMAIL PROTECTED] > > > Sent: Sunday, September 23, 2007 7:45 PM > > > To: Chuck McDevitt > > > Cc: pgsql-hackers@postgresql.org > > > Subject: Re: [HACKERS] Problem with MSVC install script > > > > > > > > > > > > Chuck McDevitt wrote: > > > > > > > > I was trying out the msvc support, and ran into a minor problem > in > > > the > > > > install.bat/install.pl > > > > > > > > If any files that are going to be installed are marked read-only, > > > they > > > > carry the read-only attribute with them when they get copied to > the > > > > install dir. > > > > > > > > Then, if you try to run install again, the new attempt will fail > > > > because it can't overwrite the read-only file. > > > > > > > > I added this like to install.bat (just before the call to > > install.pl) > > > > to fix this for me: > > > > > > > > attrib /S -r %1\* > > > > > > > > > > > > > Which files are read-only? > > > > > > cheers > > > > > > andrew > > > > > > ---(end of broadcast) > --- > > TIP 1: if posting/reading through Usenet, please send an appropriate > >subscribe-nomail command to [EMAIL PROTECTED] so that > your > >message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Problem with MSVC install script
Well, I was checking out from a different cvs server, and had things set to use CVS EDIT, where everything is read-only by default, until you issue a cvs edit command. So many files that aren't built by the build system, but just get copied as-is, end up read-only. But it would be true for any files set read-only. > -Original Message- > From: Andrew Dunstan [mailto:[EMAIL PROTECTED] > Sent: Sunday, September 23, 2007 7:45 PM > To: Chuck McDevitt > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Problem with MSVC install script > > > > Chuck McDevitt wrote: > > > > I was trying out the msvc support, and ran into a minor problem in > the > > install.bat/install.pl > > > > If any files that are going to be installed are marked read-only, > they > > carry the read-only attribute with them when they get copied to the > > install dir. > > > > Then, if you try to run install again, the new attempt will fail > > because it can't overwrite the read-only file. > > > > I added this like to install.bat (just before the call to install.pl) > > to fix this for me: > > > > attrib /S -r %1\* > > > > > Which files are read-only? > > cheers > > andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Suggestion for MSVC build
It seems like there isn't any good reason the perl scripts for the MSVC
build don't support readline
Readline for windows is available as part of the GnuWin32 project.
http://gnuwin32.sourceforge.net/packages/readline.htm
It normally installs to "c:\Program Files\GnuWin32"
I'd update the scripts myself, but I'm not a PERL programmer.
>From what I can see, you'd add another line to config.pl for readline,
and then add some stuff to mkvcbuild.pm for psql to do something like:
if ($solution->{options}->{readline})
{
$psql->AddIncludeDir($solution->{options}->{readline} . '\include');
$psql->AddLibrary($solution->{options}->{readline} .
'\lib\readline.lib');
$psql->AddLibrary($solution->{options}->{readline} .
'\lib\history.lib');
}
And something to solution.pm in the part that builds pg_config.h that
looks something like:
if ($self->{options}->{readline})
{
print O "#define
HAVE_LIBREADLINE 1\n";
print O "#define
HAVE_READLINE_READLINE_H 1\n";
print O "#define
HAVE_READLINE_HISTORY_H 1\n";
print O "#define
USE_READLINE 1\n";
print O "#define
USE_READLINE_STATIC 1\n";
}
(Not sure about the last line).
I don't know if this is a good idea, but I would think this would make
psql more "user-friendly" on windows.
Perhaps someone who understands readline and perl better than me might
want to take this on?
[HACKERS] Problem with MSVC install script
I was trying out the msvc support, and ran into a minor problem in the install.bat/install.pl If any files that are going to be installed are marked read-only, they carry the read-only attribute with them when they get copied to the install dir. Then, if you try to run install again, the new attempt will fail because it can't overwrite the read-only file. I added this like to install.bat (just before the call to install.pl) to fix this for me: attrib /S -r %1\*
Re: [HACKERS] SQL feature requests
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Florian G. Pflug
> Sent: Thursday, August 23, 2007 11:04 AM
> To: Ben Tilly
> Cc: Michael Glaesemann; Gregory Stark; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] SQL feature requests
>
> Ben Tilly wrote:
> > On 8/22/07, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
> >> On Aug 22, 2007, at 20:49 , Ben Tilly wrote:
> >>
> >>> If your implementation accepts:
> >>>
> >>> group by case when true then 'foo' end
> >> What would that mean? Regardless of whether or not it's accepted, it
> >> should have *some* meaning.
> >
> > To my eyes it has a very clear meaning, we're grouping on an
> > expression that happens to be a constant. Which happens to be the
> > same for all rows. Which is a spectacularly useless thing to
> actually
> > do, but the ability to do it happens to be convenient when I'm
> looking
> > for something to terminate a series of commas in a dynamically built
> > query.
>
> Which is the same very clear meaning that "group by 1" has - we're
> grouping on a expression which happens to be the constant 1. Hey,
> wait a second. This isn't what "group by 1" means at all - it
> rather means group by whatever the fist column in the select list is.
>
> So, yes, "group by 'foo'" *seems* to have a very clear meaning - but
> that clearness vanishes as soon as you take into account what "group by
> 1"
> means.
>
> greetings, Florian Pflug
>
Except "group by 1" meaning "group by column 1" is a PostgreSQL extension, not
a SQL standard feature, if I recall.
Anyway, I suppose this should work like ORDER BY... For some reason, we allow
all expressions in ORDER BY *except* the degenerate case of a constant (ugly).
Expressions in ORDER BY are a PostgreSQL extension also... Not sure why we
disallow the case of a constant, except somebody was worried that it would
confuse users, because simple integer constants are treated special.
But it seems strange that this is legal in PostgreSQL:
Select * from x order by trim('foo');
But this is illegal:
Select * from x order by 'foo';
And this is accepted, but orders on the constant "1" rather than on column 1:
select * from x order by 1::int;
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] SQL feature requests
> -Original Message- > From: Andrew Dunstan [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 23, 2007 10:26 AM > To: Chuck McDevitt > Cc: Tom Lane; Gregory Stark; Michael Glaesemann; Ben Tilly; pgsql- > [EMAIL PROTECTED] > Subject: Re: [HACKERS] SQL feature requests > > > > Chuck McDevitt wrote: > > Sometimes supporting "de-facto" standards as well as official > standards > > makes sense. > > > > > > > > On that basis we would support huge pieces of stuff that emulates MySQL > too. Or perhaps you'd like us to follow Oracle's treatment of NULL. Who > gets to choose what is the de facto standard we follow? > > cheers > > Andrew You must be joking... PostgreSQL already has a huge amount of "non-standard" syntax and semantics (perhaps "extensions" is a better word?). Everything from non-standard cast operator, non-standard substr, non-standard trim, non standard group by semantics (allowing simple ints to mean column number)... Given a day, we could probably write down several pages of "non-standard" features of PGSQL. Who decides what de facto standards to support, and which not? The PostgreSQL community of course. In general, we wouldn't want to support any de facto standard that: 1. Is supported only by one vendor 2. Causes any standard SQL statement to fail, or return a different answer from the standard. The proposed change doesn't fail either of these. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SQL feature requests
> > > This seems like a particularly petty case compared to a lot of other > > extensions we do allow. > > That's exactly the problem. Most of our other extensions are justified > by some significant capability gain. This isn't --- it provides zero > new functionality, and the "convenience" factor amounts to the saving > of > one keystroke (ok, maybe two if you insist on a space before the > alias). > Pretty weak argument... > > regards, tom lane > Tom, it isn't just a case of "convenience". When we are trying to convert users from another database (say Oracle for example) to PostgeSQL, one of the big stumbling blocks that slows down the work is all the little query changes that people have to make (people who might not have written the query as well), and it can require the review of hundreds or thousands of SQL scripts and applications. The harder it is, the more reluctant they are to convert. Sometimes supporting "de-facto" standards as well as official standards makes sense. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SQL feature requests
> -Original Message- > From: [EMAIL PROTECTED] [mailto:pgsql-hackers- > [EMAIL PROTECTED] On Behalf Of Chuck McDevitt > Sent: Wednesday, August 22, 2007 11:53 PM > To: Michael Glaesemann; Ben Tilly > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] SQL feature requests > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:pgsql-hackers- > > [EMAIL PROTECTED] On Behalf Of Michael Glaesemann > > Sent: Wednesday, August 22, 2007 5:17 PM > > To: Ben Tilly > > Cc: pgsql-hackers@postgresql.org > > Subject: Re: [HACKERS] SQL feature requests > > > > > > On Aug 22, 2007, at 18:45 , Ben Tilly wrote: > > > > > 1. Just a minor annoyance, but why must subqueries in FROM clauses > > > have an alias? > > > > It's required by the SQL standard, AIUI. I wonder what EnterpriseDB > > does? > > > > > 2. Why is 'non-integer constant in GROUP BY' an error? > > > > > This works for now: > > > > > > case when true then true end > > > > > > but I don't know whether some future version of postgres might > break > > > my code by banning that as well. > > 1. The SQL standard requires an alias for the subquery, but many > real-world SQL implementations relax this requirement in the case where > it is unambiguous. The standard doesn't say you have to reject > statements without the alias, it says only that you must accept the > ones > that do. PostgreSQL has many things in its SQL where we accept things > that the standard doesn't require, and I don't see a good argument why > it shouldn't allow this. > > 2. The SQL standard only allows column names in group by lists, NOT > expressions. PostgreSQL extends the standard by allowing some, but not > all, expressions in the group by list (somewhat inconsistent, in my > view). Expressions in the group by list is actually a quite common > extension. But PostgreSQL also extends the standard by attaching > special meaning to simple integer constants in the group by list, and > treating them as column numbers from the select list. As far as I > remember, the SQL standard only allows that on ORDER BY clauses. > Anyway, it seems reasonable to allow expressions in the group by, such > as: > > Select a*10, sum(b) from x group by a*10; > > But once you allow that, it seems like you should allow any expression, > even degenerate ones such as > select 'foo',sum(b) from x group by 'foo'; > Just wanted to point out that the group by thing is really just syntactic sugar. You can always get a SQL standard compliant system to accept the constants this way: Select z,sum(b) from ( Select 'foo',b from x) a1 (z,b) Group by z; This will work (although with PostgreSQL, you might have to cast the string constant to text, because it is "unknown" datatype). ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] SQL feature requests
> -Original Message- > From: [EMAIL PROTECTED] [mailto:pgsql-hackers- > [EMAIL PROTECTED] On Behalf Of Michael Glaesemann > Sent: Wednesday, August 22, 2007 5:17 PM > To: Ben Tilly > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] SQL feature requests > > > On Aug 22, 2007, at 18:45 , Ben Tilly wrote: > > > 1. Just a minor annoyance, but why must subqueries in FROM clauses > > have an alias? > > It's required by the SQL standard, AIUI. I wonder what EnterpriseDB > does? > > > 2. Why is 'non-integer constant in GROUP BY' an error? > > > This works for now: > > > > case when true then true end > > > > but I don't know whether some future version of postgres might break > > my code by banning that as well. 1. The SQL standard requires an alias for the subquery, but many real-world SQL implementations relax this requirement in the case where it is unambiguous. The standard doesn't say you have to reject statements without the alias, it says only that you must accept the ones that do. PostgreSQL has many things in its SQL where we accept things that the standard doesn't require, and I don't see a good argument why it shouldn't allow this. 2. The SQL standard only allows column names in group by lists, NOT expressions. PostgreSQL extends the standard by allowing some, but not all, expressions in the group by list (somewhat inconsistent, in my view). Expressions in the group by list is actually a quite common extension. But PostgreSQL also extends the standard by attaching special meaning to simple integer constants in the group by list, and treating them as column numbers from the select list. As far as I remember, the SQL standard only allows that on ORDER BY clauses. Anyway, it seems reasonable to allow expressions in the group by, such as: Select a*10, sum(b) from x group by a*10; But once you allow that, it seems like you should allow any expression, even degenerate ones such as select 'foo',sum(b) from x group by 'foo'; ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] libpq protocol version 2
Is protocol version 2 still used by anything? Is there a reason why this is still supported? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Selecting a constant question: A summary
I see... PostgreSQL wants to guess the datatype, given no clear syntactic information, and perhaps a varchar(n) wouldn't be a valid cast to some of the possible datatypes. So, where x = '(1,2)' might be legal for comparing to x, but a field of type varchar(5) might not be, as in where x = y, where y is type varchar(5) containing '(1,2)'. (Time values don't have this problem in pure ANSI SQL, since the literal is TIME '12:34', but I can see for user types it might be ambiguous). I find PostgreSQL's handling of this strange, as I come from systems where 'xxx' is either a varchar or char type, in all contexts, and implicit casts handle any needed conversions. But now I understand why it does things this way. Thanks. -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 12, 2007 9:50 PM To: Chuck McDevitt Cc: Andrew Hammond; Josh Berkus; pgsql-hackers@postgresql.org; Dann Corbit; Larry McGhaw Subject: Re: [HACKERS] Selecting a constant question: A summary "Chuck McDevitt" <[EMAIL PROTECTED]> writes: > Just a curiosity question: Why is the type of a literal '1' "unknown" > instead of varchar(1)? Because, for instance, it might be intended as an integer or float or numeric value. Change the content a little, like '(1,2)' or '12:34', and maybe it's a point or time value. There are plenty of contexts in which the intended type of a literal is obviously not text/varchar. We assign unknown initially as a way of flagging that the type assignment is uncertain. Once we have a value that we think is varchar (a table column for instance), the rules for deciding to cast it to a different type get a lot more stringent. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Selecting a constant question: A summary
Just a curiosity question: Why is the type of a literal '1' "unknown" instead of varchar(1)? Wouldn't varchar(1) cast properly to any use of the literal '1'? What is the benefit of assuming it's an unknown? ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Why is this allowed?
Ok... Just to be clear, the ISO SQL spec says that INTERVAL '1' DAY is the correct way to specify a one-day interval. That's why it is surprising that PostgreSQL treats it differently, with no error or warning. The PostgreSQL syntax INTERVAL '1 DAY' is non-standard. Is fixing this on the TODO list? -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Saturday, March 10, 2007 5:11 PM To: Gregory Stark Cc: Chuck McDevitt; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Why is this allowed? Gregory Stark <[EMAIL PROTECTED]> writes: > "Chuck McDevitt" <[EMAIL PROTECTED]> writes: >> Why don't we have some kind of error check for people entering things >> like INTERVAL '1' DAY in their query, since we don't handle it. > Because it's not an error. It just doesn't mean what you think it means. What it is is an incompletely implemented feature. That syntax is required by the SQL spec, and Tom Lockhart had been making progress towards supporting it when he got bored and left the project. Where he left it is that the grammar accepts it but the interval input routine isn't paying any attention to the qualifier. I'm not eager to rip out what's there, but I don't personally feel like making it work either... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Why is this allowed?
Why don't we have some kind of error check for people entering things like INTERVAL '1' DAY in their query, since we don't handle it. select now() =now() + interval '1' day; ?column? -- T This seems scary... We allow something through and then ignore it? "Interval '1 day'" or "interval '1 day' day " both work.
Re: [HACKERS] [SQL] Case Preservation disregarding case
Sorry, my last mail wasn't well thought out. Yes, the information_schema needs the case-folded name (although it might be ok to add additional columns to the information_schema for extra information). But, stepping back from all that, what is it the users want? 1) When re-creating a CREATE TABLE statement from whatever catalog info, they'd like the names to come back exactly as then entered them. If I do: CREATE TABLE BobsTable (WeeklySales numeric(10,2), "SomeStrangeName" int); They'd like to see exactly that when the CREATE TABLE gets re-created, not what we do now: CREATE TABLE bobstable (weeklysales numeric(10,2), "SomeStrangeName" int); 2) When doing reports, they'd like the name as entered to be the title of the column: Select * from bobstable; Would be nice if they saw this: WeeklySalesSomeStrangeName ------ For compatibility with existing apps and spec compliance, you'd still want PQfname() to return the case-folded name. But there isn't any reason you couldn't also return a "suggested title" field (PQftitle?) which preserves the user's case. You could also extend the concept of a PQftitle to make nicer titles for expressions. Instead of SELECT sum(WeeklySales) from BobsTable; Producing "?column?" or somesuch to use in the report, it could return a title like "sum(WeeklySales)" -Original Message----- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 10:38 PM To: Chuck McDevitt Cc: Stephan Szabo; beau hargis; pgsql-sql@postgresql.org; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] [SQL] Case Preservation disregarding case "Chuck McDevitt" <[EMAIL PROTECTED]> writes: > Equivalent, yes. But I can interpret that clause it mean I can show > either the case folded or non-case-folded value in the information > schema, as they are equivalent. Well, that's an interesting bit of specs-lawyering, but I don't see how you can defend it against these rules in SQL99 5.2: 21) For every IB there is exactly one corresponding case-normal form CNF. CNF is an derived from IB as follows. Let n be the number of characters in IB. For i ranging from 1 (one) to n, the i-th character M(i) of IB is translated into the corresponding character or characters of CNF as follows. Case: a) If M(i) is a lower case character or a title case character for which an equivalent upper case sequence U is defined by Unicode, then let j be the number of characters in U; the next j characters of CNF are U. b) Otherwise, the next character of CNF is M(i). 22) The case-normal form of the of a is used for purposes such as and including determination of identifier equivalence, representation in the Definition and Information Schemas, and representation in diagnostics areas. NOTE 44 - Any lower-case letters for which there are no upper- case equivalents are left in their lower-case form. Again, obviously we are not compliant because we fold to lower rather than upper case, but I do not see how you can read (22) as not requiring the information schema to show the upper-cased form. The output of functions such as PQfname() might be considered closer to diagnostics info than information schema, but that's covered too. But the really serious problem with what you propose is that it would allow two table columns with names that the system considers distinct to show as the same string in the information schema and diagnostic outputs. That can't be acceptable --- it's going to break any application that does any nontrivial analysis of what it sees there, not to mention that it violates various primary key constraints in the information schema specification. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [SQL] Case Preservation disregarding case
-Original Message- From: Stephan Szabo [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 10:23 AM To: Chuck McDevitt Cc: Tom Lane; beau hargis; pgsql-sql@postgresql.org; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] [SQL] Case Preservation disregarding case On Tue, 31 Oct 2006, Chuck McDevitt wrote: > We treated quoted identifiers as case-specific, as the spec requires. > > In the catalog, we stored TWO columns... The column name with case > converted as appropriate (as PostgreSQL already does), used for looking > up the attribute, > And a second column, which was the column name with the case exactly as > entered by the user. Wouldn't using that second column's value tend to often violate 5.2SR10 (at least that's the reference item in SQL92)? AFAICT, that rule basically says that the regular identifier is equivalent to the case-folded one for purposes of information and definition schema and similar purposes which seems like it would be intended to include things like column labeling for output. There's a little bit of flexibility there on both similar purposes and equivalence, though. Equivalent, yes. But I can interpret that clause it mean I can show either the case folded or non-case-folded value in the information schema, as they are equivalent. Anyway, we have many things that are "enhancements" beyond the spec, and this could also be considered an enhancement. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [SQL] Case Preservation disregarding case
Oh... And Microsoft SQLServer does something similar. At Greenplum, we've already gotten complaints from customers about this when they were switching from MSSQL to GP's PostgreSQL-based database. -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Monday, October 30, 2006 10:35 PM To: Chuck McDevitt Cc: beau hargis; pgsql-sql@postgresql.org; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] [SQL] Case Preservation disregarding case sensitivity? "Chuck McDevitt" <[EMAIL PROTECTED]> writes: > At Teradata, we certainly interpreted the spec to allow case-preserving, > but case-insensitive, identifiers. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [SQL] Case Preservation disregarding case
We treated quoted identifiers as case-specific, as the spec requires. In the catalog, we stored TWO columns... The column name with case converted as appropriate (as PostgreSQL already does), used for looking up the attribute, And a second column, which was the column name with the case exactly as entered by the user. So, your example would work just fine. -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Monday, October 30, 2006 10:35 PM To: Chuck McDevitt Cc: beau hargis; pgsql-sql@postgresql.org; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] [SQL] Case Preservation disregarding case sensitivity? "Chuck McDevitt" <[EMAIL PROTECTED]> writes: > At Teradata, we certainly interpreted the spec to allow case-preserving, > but case-insensitive, identifiers. Really? As I see it, the controlling parts of the SQL spec are (SQL99 sec 5.2) 26) A and a are equivalent if the of the (with every letter that is a lower-case letter replaced by the corresponding upper-case letter or letters) and the of the (with all occurrences of replaced by and all occurrences of replaced by ), considered as the repetition of a that specifies a of SQL_IDENTIFIER and an implementation-defined collation that is sensitive to case, compare equally according to the comparison rules in Subclause 8.2, "". 27) Two s are equivalent if their s, considered as the repetition of a that specifies a of SQL_IDENTIFIER and an implementation-defined collation that is sensitive to case, compare equally according to the comparison rules in Subclause 8.2, "". Note well the "sensitive to case" bits there. Now consider CREATE TABLE tab ( "foobar" int, "FooBar" timestamp, "FOOBAR" varchar(3) ); We can *not* reject this as containing duplicate column names, else we have certainly violated rule 27. Now what will you do with SELECT fooBar FROM tab; ? The spec is unquestionably on the side of "you selected the varchar column"; historical Postgres practice is on the side of "you selected the int column". AFAICS a case-insensitive approach would have to fail with some "I can't identify which column you mean" error. I am interested to see where you find support for that in the spec... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [SQL] Case Preservation disregarding case
At Teradata, we certainly interpreted the spec to allow case-preserving, but case-insensitive, identifiers. Users really liked it that way: If you re-created a CREATE TABLE statement from the catalog, you could get back exactly the case the user had entered, but people using the table didn't need to worry about case. And column titles in reports would have the nice case preserving information. Sort of like how Windows systems treat file names... The case is preserved, but you don't need to know it to access the file. I know UNIX users usually think "case-preserving with case-insensitive" a foreign concept, but that doesn't mean the average user feels the same. If I want my column named "WeeklyTotalSales", I really don't want to have to always quote it and type in the exact case. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: Monday, October 30, 2006 7:24 PM To: beau hargis Cc: pgsql-sql@postgresql.org; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] [SQL] Case Preservation disregarding case sensitivity? beau hargis <[EMAIL PROTECTED]> writes: > Considering the differences that already exist between database systems and > their varying compliance with SQL and the various extensions that have been > created, I do not consider that the preservation of case for identifiers > would violate any SQL standard. That's not how I read the spec. It is true that we are not 100% spec compliant, but that isn't a good argument for moving further away from spec. Not to mention breaking backwards compatibility with our historical behavior. The change you propose would fix your application at the cost of breaking other people's applications. Perhaps you should consider fixing your app instead. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Upgrading a database dump/restore
-Original Message- I think we had that problem solved too in principle: build the new catalogs in a new $PGDATA directory alongside the old one, and hard-link the old user table files into that directory as you go. Then pg_upgrade never needs to change the old directory tree at all. This gets a bit more complicated in the face of tablespaces but still seems doable. (I suppose it wouldn't work in Windows for lack of hard links, but anyone trying to run a terabyte database on Windows deserves to lose . regards, tom lane ---(end of broadcast)--- FYI: Windows NTFS has always supported hard links. It was symlinks it didn't support until recently (now it has both). And there isn't any reason Terabyte databases shouldn't work as well on Windows as on Linux, other than limitations in PostgreSQL itself. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] src/tools/msvc usage instructions
From my experience with Visual C++, using /Za isn't a good idea. When you set that, the compiler become very pedantic about following the ANSI speck to the letter, which usually means common posix functions aren't available under their normal names (The ansi spec says if the compiler defines functions beyond what in the spec, it's recommended they start with "_" to not conflict with application name space). Compatibility with GCC is reduced when you use /Za. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: Tuesday, October 03, 2006 8:51 AM To: Magnus Hagander Cc: Jeremy Drake; PostgreSQL Hackers Subject: Re: [HACKERS] src/tools/msvc usage instructions "Magnus Hagander" <[EMAIL PROTECTED]> writes: >> which looks like they figured out that they needed to check >> for MicroSoft C explicitly. I have no idea why they do not >> define __STDC__ however. > Can we just define __STDC__ when compiling that file (or rather, when > compiling any bison-generated output file)? Or is that likely to cause > *other* issues? That seems pretty risky. Better to use the /Za switch or whatever it was to get the compiler to assert it for itself. We have precedent for adding yes-we'd-like-a-standard-compiler-please switches where necessary, for instance adding -Ae to CFLAGS for HP's compiler. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
pgsql-hackers@postgresql.org
Statically link the c library, and your problem is solved. Or ship the dll with the installer, like any normal commercial application would. Microsoft specifically grants the right to do this. There is no other "runtime" besides the c library. Either approach is simple, and doesn't tie us to an ancient compiler (Well, it came out in the end of 1998, and I consider it ancient). > -Original Message- > From: Dave Page [mailto:[EMAIL PROTECTED] > Sent: Friday, May 05, 2006 3:12 PM > To: Chuck McDevitt; [EMAIL PROTECTED]; [EMAIL PROTECTED]; pgsql- > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [pgsql-hackers-win32] [HACKERS] Build with Visual Studio & > > > > -Original Message- > From: "Chuck McDevitt"<[EMAIL PROTECTED]> > Sent: 05/05/06 18:01:49 > To: "Magnus Hagander"<[EMAIL PROTECTED]>, "Gurjeet > Singh"<[EMAIL PROTECTED]>, "pgsql-hackers@postgresql.org" [EMAIL PROTECTED]>, "[EMAIL PROTECTED]"<[EMAIL PROTECTED]> > Subject: Re: [pgsql-hackers-win32] [HACKERS] Build with Visual Studio & > > > I don't see any reason we'd want to target VC++6.0. > > The runtimes ship with every platform we support, unlike v7 or v8. > > Regards, Dave > > -Unmodified Original Message- > VC++6.0 isn't a very good compiler and it's not very compatible with > gcc, while Visual Studio 2005 compiler is much more compatible and has a > better optimizer. > > Plus, VC++6.0 had a closed "proprietary" data format for .dsp and .dsw > files, while the current Visual Studio uses a standard XML format. > > Finally, Microsoft gives away (as in free, no cost) Visual C++ Express > edition, which includes the current compiler. > > I don't see any reason we'd want to target VC++6.0. > > > P.s. With the current Visual Studio, it's easy to add Bison and Flex > custom rules, so that it automatically calls them for .y and .l files. > > -Original Message- > From: Magnus Hagander [mailto:[EMAIL PROTECTED] > Sent: Friday, May 05, 2006 12:42 AM > To: Gurjeet Singh; pgsql-hackers@postgresql.org; [EMAIL PROTECTED]; > Chuck McDevitt > Subject: RE: [pgsql-hackers-win32] [HACKERS] Build with Visual Studio & > MSVC > > > Hi William(uniware), Chuck and Hackers, > > > > I have been interested in doing complete PGSQL > > development in MSVC for a long time now. With reference to > > one of Chuck's mails to > > -hackers-win32 with the same subject, you said that you were > > able to successfully compile PG 8.1 with some minor tweaks. > > > > Also, William has 'vcproject' hosted on pgfoundry, I > > downloaded it, and tried compiling > > vcproject\msvc\postgres\postgres.dsw on > > VC++6.0. It failed miserably with over 1000 errors. I am sure there's > > some tweaks needed here too!!! > > Yes. There is a patch pending on -patches which fix almost all of these > in HEAD. (There are a few tiny things related to perl and NLS that > aren't included in it ATM. And I'm just assuming you're seeing the same > problems as I was but I didn't base my work off vcproject). I'm also > working on a buildscript to convert the Makefiles to visual c++ project > files, but that's not quite done yet. The idea with this work is to have > the stuff as integrated as possible with main CVS, so the maintenance > will be as low as possible - unlike the vcproject project which has been > focusing on keeping a separate build environment maintained. > > The target is VC++ 2003 and 2005 ATM, but it should just be a matter of > a different output format for VC 6.0 I guess. > > You will still need things like bison and flex if you want to build off > cvs, of course - there is no builtin support for that in VC++. > > > //Magnus > > > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
pgsql-hackers@postgresql.org
VC++6.0 isn't a very good compiler and it's not very compatible with gcc, while Visual Studio 2005 compiler is much more compatible and has a better optimizer. Plus, VC++6.0 had a closed "proprietary" data format for .dsp and .dsw files, while the current Visual Studio uses a standard XML format. Finally, Microsoft gives away (as in free, no cost) Visual C++ Express edition, which includes the current compiler. I don't see any reason we'd want to target VC++6.0. P.s. With the current Visual Studio, it's easy to add Bison and Flex custom rules, so that it automatically calls them for .y and .l files. -Original Message- From: Magnus Hagander [mailto:[EMAIL PROTECTED] Sent: Friday, May 05, 2006 12:42 AM To: Gurjeet Singh; pgsql-hackers@postgresql.org; [EMAIL PROTECTED]; Chuck McDevitt Subject: RE: [pgsql-hackers-win32] [HACKERS] Build with Visual Studio & MSVC > Hi William(uniware), Chuck and Hackers, > > I have been interested in doing complete PGSQL > development in MSVC for a long time now. With reference to > one of Chuck's mails to > -hackers-win32 with the same subject, you said that you were > able to successfully compile PG 8.1 with some minor tweaks. > > Also, William has 'vcproject' hosted on pgfoundry, I > downloaded it, and tried compiling > vcproject\msvc\postgres\postgres.dsw on > VC++6.0. It failed miserably with over 1000 errors. I am sure there's > some tweaks needed here too!!! Yes. There is a patch pending on -patches which fix almost all of these in HEAD. (There are a few tiny things related to perl and NLS that aren't included in it ATM. And I'm just assuming you're seeing the same problems as I was but I didn't base my work off vcproject). I'm also working on a buildscript to convert the Makefiles to visual c++ project files, but that's not quite done yet. The idea with this work is to have the stuff as integrated as possible with main CVS, so the maintenance will be as low as possible - unlike the vcproject project which has been focusing on keeping a separate build environment maintained. The target is VC++ 2003 and 2005 ATM, but it should just be a matter of a different output format for VC 6.0 I guess. You will still need things like bison and flex if you want to build off cvs, of course - there is no builtin support for that in VC++. //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Should libedit be preferred to
Another vote for libedit support... We at Greenplum definitely want to use it. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Another pgindent gripe
Pgindent adds spaces after the stars if it doesn't recognize the thing before the star as a typedef... Could it be that somehow the list of typedefs included in pgindent got corrupted? > -Original Message- > From: [EMAIL PROTECTED] [mailto:pgsql-hackers- > [EMAIL PROTECTED] On Behalf Of Tom Lane > Sent: Monday, November 07, 2005 8:19 AM > To: Neil Conway > Cc: Bruce Momjian; Hackers > Subject: Re: [HACKERS] Another pgindent gripe > > Neil Conway <[EMAIL PROTECTED]> writes: > > On a related note, most of these changes are completely bogus: > > > > http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_e xe > c.c.diff?r1=1.152;r2=1.153 > > Oy vey! Why did it insert spaces after the stars in all those function > declarations? That's certainly not in conformance with project style > ... and I don't see it having happened elsewhere. > > Seems like pgindent has suffered some significant regressions since the > 8.0 run. I thought it had not been changed much at all, but evidently > that's wrong. > > regards, tom lane > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Build with Visual Studio & MSVC
Just for fun, I went through PostgreSQL 8.1 and did a complete build using Microsoft’s C and the latest Visual Studio. With a few minor tweaks, everything compiled with no errors. My assumption is that because PostgreSQL is a UNIX/Linux-centric project (and gcc/gdb centric), this really isn’t of much interest to anyone. So other than this e-mail, I don’t plan to do anything with this except for my own amusement. If I’m wrong, and there is some real interest in supporting MSVC, let me know, and I’ll put some work into cleaning it up and making patches out of it, etc.
Re: [HACKERS] Windows + IP6 progress
The advantage of doing the check at run-time is that you can build PostgreSQL on one machine (which has IPv6), and have it run on some other windows box (which might not have IPv6). So you'd only need one set of binaries. Routines like "getopt" are not __stdcall, so their names don't get mangled. Only actual calls to the Win32 API would likely be __stdcall. > -Original Message- > From: Andrew Dunstan [mailto:[EMAIL PROTECTED] > Sent: Friday, August 19, 2005 5:22 AM > To: Tom Lane > Cc: Chuck McDevitt; PostgreSQL-development > Subject: Re: [HACKERS] Windows + IP6 progress > > > > Tom Lane wrote: > > >Andrew Dunstan <[EMAIL PROTECTED]> writes: > > > > > >>Chuck McDevitt wrote: > >> > >> > >>>I think it's because it's __stdcall, and the name gets mangled to > >>>include the number of parameters. > >>> > >>> > > > > > > > >>Aha! now it makes sense. How do we get around that in the configure > tests? > >> > >> > > > >I thought it might be something like that ... but the question remains: > >how/why is getaddrinfo different from all the other library routines we > >probe for? > > > > > > > > > > I think many if not all of those that succeed come from the mingw > libraries. For example, the Windows libraries don't have getopt at all, > I believe. > > But I confess I don't understand enough about how it works to give a > definitive answer. > > Meanwhile, Petr Jelinek reports that the binaries I made fail on Windows > versions as modern as Windows 2000 (missing freeaddrinfo). Darn. > > So the choices appear to be: > a) check for all the required functions at runtime, and otherwise use > our homegrown getaddrinfo and friends (and don't support ipv6) > b) teach our getaddrinfo and friends about ipv6 > c) have a configure flag (--enable-win-ipv6 ? ) for those Windows > platforms that do/don't support ipv6. That would mean 2 sets of > binaries ;-( > d) don't support ipv6 in windows. > e) something else I haven't thought of > > Looks to me like a) is the best bet, but it's beyond my Windows > programming capacity and experience. We do something of the sort with > src/interfaces/libpq/win32.c. Maybe Chuck or Petr could come up with a > patch? > > cheers > > andrew > ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Windows + IP6 progress
I think it's because it's __stdcall, and the name gets mangled to include the number of parameters. > -Original Message- > From: Andrew Dunstan [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 18, 2005 4:44 PM > To: Chuck McDevitt > Cc: Tom Lane; PostgreSQL-development > Subject: Re: [HACKERS] Windows + IP6 progress > > > The mingw header has pretty much this with WINSOCK_API_LINKAGE IN OUT > and FAR dissolved away. > > The standard test complains about it being an unresolved reference when > it is declared as "char getaddrinfo (); ". If we remove that and instead > include the header the test passes. I have no idea why that should be > the case for this function and not for others. > > cheers > > andrew > > > Chuck McDevitt wrote: > > >The definition in WS2tcpip.h > > > >WINSOCK_API_LINKAGE > >int > >WSAAPI > >getaddrinfo( > >IN const char FAR * nodename, > >IN const char FAR * servname, > >IN const struct addrinfo FAR * hints, > >OUT struct addrinfo FAR * FAR * res > >); > > > > > >(IN, FAR, and OUT are #defined to empty string). > > > >WINSOCK_API_LINKAGE is __declspec(dllimport) > >WSAAPI is __stdcall > > > >So, nothing magic with #defines of the name getaddrinfo. > > > > > > > > > >>-Original Message- > >>From: [EMAIL PROTECTED] [mailto:pgsql-hackers- > >>[EMAIL PROTECTED] On Behalf Of Tom Lane > >>Sent: Thursday, August 18, 2005 3:47 PM > >>To: Andrew Dunstan > >>Cc: PostgreSQL-development > >>Subject: Re: [HACKERS] Windows + IP6 progress > >> > >>Andrew Dunstan <[EMAIL PROTECTED]> writes: > >> > >> > >>>. what do we do about the getaddrinfo test? I'm almost inclined not > >>> > >>> > >to > > > > > >>>do it on windows, and assume that if we have ws2_32.dll we have it. > >>> > >>> > >>There's something mighty fishy about that. AC_REPLACE_FUNCS works on > >>Windows for the other cases it's used for (no?), so what's different > >>about getaddrinfo? Perhaps Microsoft has #define'd that name as > >>something else, or some equally ugly crock? It'd be useful to look > >> > >> > >into > > > > > >>their header files and see exactly how and where getaddrinfo is > >>declared. > >> > >>regards, tom lane > >> > >>---(end of > >> > >> > >broadcast)--- > > > > > >>TIP 3: Have you checked our extensive FAQ? > >> > >> http://www.postgresql.org/docs/faq > >> > >> > > > > > > > > ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Windows + IP6 progress
IPv6 exists in a "production quality" state only in XP sp1, XP sp2, and
Windows 2003.
There was an optional prototype stack for 2000, but not production
quality and not installed by default. XP non-service-pack had IPv6,
but not production-quality.
One thing you could do is dynamically load getaddrinfo from ws2_32.dll
at run time. If the DLL doesn't exist, or getaddrinfo isn't in that
ws2_32.dll, you could then fail gracefully (somehow).
You call something like:
hWs2_32 = LoadLibraryA("ws2_32.dll");
if (hWs2_32)
{
Getaddrinfoptr = GetProcAddress(hWs2_32, "getaddrinfo");
}
The GetProcAddress will return null if getaddrinfo doesn't exist, and a
pointer to the routine if it does.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Andrew Dunstan
> Sent: Thursday, August 18, 2005 3:17 PM
> To: PostgreSQL-development
> Subject: [HACKERS] Windows + IP6 progress
>
>
> I have just managed to get pg server and client (cvs tip) talking IPv6
> on Windows. :-)
>
> 1. Building
> - added in library in configure.in:
> AC_CHECK_LIB(ws2_32, main)
> - faked out getaddrinfo test in resulting configure and force
answer
> to "yes"
> - added these lines to src/include/port/win32/sys/socket.h:
> #include
> #define gai_strerrorA(err) "undetermined getaddrinfo error"
>
> After installation and initdb, I edited postgresql.conf to set
> listen_addresses to '127.0.0.1, ::1' just to make sure what we were
> getting.
>
> 2. Running without IPv6 driver installed.
> The build works, although it complains about IPv6 addresses. But I
> could run it with IPv4 addresses quite happily - the IPv6 addresses
just
> fail, but they don't stop us running.
>
> 3. Running with IPv6 driver installed
>Now the build does not complain about IPv6 addresses (either in
> pg_hba.conf or postgresql.conf)
>And this command works: psql -h ::1 -l
>
>
> So the remaining questions are:
> . what do we do about the getaddrinfo test? I'm almost inclined not to
> do it on windows, and assume that if we have ws2_32.dll we have it.
> . what to do about the gai_strerror mess (import our own but leave out
> our own getaddrinfo?)
> . make sure that this doesn't break less modern Windows platforms than
> mine (XP Pro SP1). How ubiquitous is ws2_32.dll?
>
> I have asked a few people to test this build. I don't want to publish
> its location openly, but if anyone wants to help they can drop me an
> email. Alternatively, some kind person could provide a site on a nice
> fat pipe for an 18Mb download.
>
>
> cheers
>
> andrew
>
> ---(end of
broadcast)---
> TIP 6: explain analyze is your friend
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] Windows + IP6 progress
The definition in WS2tcpip.h WINSOCK_API_LINKAGE int WSAAPI getaddrinfo( IN const char FAR * nodename, IN const char FAR * servname, IN const struct addrinfo FAR * hints, OUT struct addrinfo FAR * FAR * res ); (IN, FAR, and OUT are #defined to empty string). WINSOCK_API_LINKAGE is __declspec(dllimport) WSAAPI is __stdcall So, nothing magic with #defines of the name getaddrinfo. > -Original Message- > From: [EMAIL PROTECTED] [mailto:pgsql-hackers- > [EMAIL PROTECTED] On Behalf Of Tom Lane > Sent: Thursday, August 18, 2005 3:47 PM > To: Andrew Dunstan > Cc: PostgreSQL-development > Subject: Re: [HACKERS] Windows + IP6 progress > > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > . what do we do about the getaddrinfo test? I'm almost inclined not to > > do it on windows, and assume that if we have ws2_32.dll we have it. > > There's something mighty fishy about that. AC_REPLACE_FUNCS works on > Windows for the other cases it's used for (no?), so what's different > about getaddrinfo? Perhaps Microsoft has #define'd that name as > something else, or some equally ugly crock? It'd be useful to look into > their header files and see exactly how and where getaddrinfo is > declared. > > regards, tom lane > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Feature freeze date for 8.1
> -Original Message- > From: [EMAIL PROTECTED] [mailto:pgsql-hackers- > [EMAIL PROTECTED] On Behalf Of Dave Held > Sent: Tuesday, May 03, 2005 3:41 PM > To: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Feature freeze date for 8.1 > > > -Original Message- > > From: Tom Lane [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, May 03, 2005 4:20 PM > > To: Dave Held > > Cc: pgsql-hackers@postgresql.org > > Subject: Re: [HACKERS] Feature freeze date for 8.1 > > > > > > "Dave Held" <[EMAIL PROTECTED]> writes: > > > How about an optional second connection to send keepalive pings? > > > It could be unencrypted and non-blocking. If authentication is > > > needed on the ping port (which it doesn't seem like it would need > > > to be), it could be very simple, like this: > > > > > * client connects to main port > > > * server authenticates client normally > > > * server sends nonce token for keepalive authentication > > > * client connects to keepalive port > > > * client sends nonce token on keepalive port > > > * server associates matching keepalive connection with main > > > connection > > > * if server does not receive matching token within a small > > > timeout, no keepalive support enabled for this session > > > > > > This seems to have nothing whatever to do with the stated problem? > > I thought the problem was a server process that loses a > connection to a client sticking around and consuming resources. > And then I thought a possible solution was to try to see if > the client is still alive by sending it an occasional packet. > And then I thought a new problem is sending packets to an > unresponsive client and filling up the output buffer and > blocking the server process. > > So it seems that a possible solution to that problem is to > have a separate connection for keepalive packets that doesn't > block and doesn't interfere with normal client/server > communication. > > Now granted, it is possible that the primary connection could > die and the secondary is still alive. So let's consider the > likely failure modes: > > * physical network failure > > In this case, I don't see how the secondary could survive while > the primary dies. > > * client hangs or dies > > If the client isn't reading keepalives from the server, > eventually the server's send queue will fill and the server > will see that the client is unresponsive. The only way the > client could fail on the primary while responding on the > secondary is if it makes the connections in different threads, > and the primary thread crashes somehow. At that point, I would > hope that the user would notice that the client has died and > shut it down completely. Otherwise, the client should just not > create a separate thread for responding to keepalives. > > * transient network congestion > > It's possible that a keepalive could be delayed past the > expiration time, and the server would assume that the client > is dead when it's really not. Then it would close the client's > connection rather rudely. But then, since there's no reliable > way to tell if a client is dead or not, your other option is to > consume all your connections on maybe-dead clients. > > So what am I missing? > > __ > David B. Held > Software Engineer/Array Services Group > 200 14th Ave. East, Sartell, MN 56377 > 320.534.3637 320.253.7800 800.752.8129 > 1) Adding a separate connection means managing that connection, making sure it gets connected/disconnected at the right times, and that it can traverse the same firewalls as the primary connection. 2) You'd need another process or another thread to respond on the secondary connection. If it's another process, the primary process could die/hang while the keepalive process keeps working (or vice versa). If it's another thread, you are forcing all clients to support multithreading. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Feature freeze date for 8.1
> -Original Message- > From: Oliver Jowett [mailto:[EMAIL PROTECTED] > Sent: Monday, May 02, 2005 3:06 PM > To: Chuck McDevitt > Cc: Tom Lane; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Feature freeze date for 8.1 > > Chuck McDevitt wrote: > > > Why not just use SO_KEEPALIVE on the TCP socket? > > We already do, but the default keepalive interval makes it next to useless. > > -O So, change the default. On Linux it's in /proc/sys/net/ipv4/tcp_keepalive_time Admittedly, this isn't a great solution, but it had the advantage of being simple. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Feature freeze date for 8.1
> -Original Message- > From: [EMAIL PROTECTED] [mailto:pgsql-hackers- > [EMAIL PROTECTED] On Behalf Of Tom Lane > Sent: Monday, May 02, 2005 1:17 PM > To: [EMAIL PROTECTED] > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Feature freeze date for 8.1 > > Andrew - Supernews <[EMAIL PROTECTED]> writes: > > Then the client has to guarantee that it can stop whatever it was doing > > (which might have nothing to do with the database) every so often in > > order to send a message; this isn't feasible for most clients. > > It's certainly infeasible for libpq, which has no portable way to force > the calling app to give it control. > > regards, tom lane Why not just use SO_KEEPALIVE on the TCP socket? Then the TCP stack handles sending the keepalive messages, and there is no requirement that the client application give control to anything... It's all handled by the TCP stack. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Woo hoo ... a whole new set of compiler
> -Original Message- > From: [EMAIL PROTECTED] [mailto:pgsql-hackers- > [EMAIL PROTECTED] On Behalf Of Dave Held > Sent: Friday, April 22, 2005 10:23 AM > To: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler > headaches!! :) > > > -Original Message- > > From: Alvaro Herrera [mailto:[EMAIL PROTECTED] > > Sent: Friday, April 22, 2005 12:06 PM > > To: Tom Lane > > Cc: Dave Held; pgsql-hackers@postgresql.org > > Subject: Re: [HACKERS] Woo hoo ... a whole new set of compiler > > headaches!! :) > > > > [...] > > Why don't we rewrite Postgres in D? > > > > http://www.digitalmars.com/d/ > > > > :-D > > I see the smiley, but moving to C++ isn't just about switching > to the latest fad language. First of all, you would literally > have to rewrite it to use D. There would probably need to be > very little work to make the Postgres codebase a conforming set > of C++ programs (mostly renaming variables/types named 'class', > 'virtual', 'bool', etc.). Second, you can find a decent C++ > compiler on virtually every platform that has a C compiler. > Third, C++ offers real advantages in type safety, exception > handling, resource management, and even performance. > > Even doing something as simple as writing a stored procedure > in C is somewhat awkward because of all the boilerplate casting > that must be done. I'm fairly certain that most of the macros > in the stored procedure interface could go away if a C++ API > were created. > > __ > David B. Held I've done extensive coding in both C and C++, and I have to agree with David. C++ is "a better C", and if used properly, there isn't any performance penalty. C++ code has better checking from the compiler, and can often be written in ways that make the code far more readable. That said, getting people to change is definitely an uphill battle. The open-source community tends to be very focused on C, and very reluctant to change. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] argtype_inherit() is dead code
Can you tell me more about the good ODBC driver being worked on? I was thinking of working on this myself, but if someone is already solving the problem, that's great! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua D. Drake Sent: Sunday, April 17, 2005 6:56 AM To: Alvaro Herrera Cc: Tom Lane; elein; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] argtype_inherit() is dead code > Is it really an important area to improve, or are there other > priorities? I know some people wished we had better support for > inheritance, but how strong is that wish? Hello, From a "people who call me" perspective. I am never asked about inheritance. Most of the people don't even know it is there. The requests I get are: Replication (obviously solved) Multi-Master Replication (working on it ;)) Table Partitioning (No great solution) IN/OUT Parameteres (being working on) Good ODBC driver (Soon to be solved) I get others of course but those are the ones that seem to raise their head the most. Sincerely, Joshua D. Drake > > -- Command Prompt, Inc., Your PostgreSQL solutions company. 503-667-4564 Custom programming, 24x7 support, managed services, and hosting Open Source Authors: plPHP, pgManage, Co-Authors: plPerlNG Reliable replication, Mammoth Replicator - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
