[GENERAL] Adapting existing extensions to use CREATE EXTENSION
Hi folks, I've been looking at converting my existing "debversion" datatype extension to use the proper "CREATE EXTENSION" facility for 9.1, while also being backward compatible with 8.4 and 9.0. My initial work on the conversion is here: http://people.debian.org/~rleigh/postgresql-debversion_1.0.5.orig.tar.gz (this is based upon looking at how citext handles it plus the documentation and information at pgxn.org) Note that it uses autoconf/make rather than relying on PGXS. Extension support is disabled with --disable-extension. When disabled, it still installs a compatibility script in contrib/ to allow existing scripts to function (but it just wraps CREATE EXTENSION rather than doing everything by hand). I was wondering if anyone could possibly look it over to see if I'm missing anything, or doing anything stupid that I shouldn't in the new order of things. I'll release it and make it available on PGXN once I'm happy it's OK. Many thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: [GENERAL] Adapting existing extensions to use CREATE EXTENSION
On Mon, Aug 15, 2011 at 08:41:06PM +0200, Dimitri Fontaine wrote: > Hi, > > Roger Leigh writes: > > I've been looking at converting my existing "debversion" datatype > > extension to use the proper "CREATE EXTENSION" facility for 9.1, > > while also being backward compatible with 8.4 and 9.0. > > I've been doing the same exercise with pgfincore recently, and will > probably do some more of it later. You can look at those links for the > time being: > > http://tapoueh.org/blog/2011/06/29-multi-version-support-for-extensions.html > https://github.com/klando/pgfincore/tree/master/debian > http://packages.debian.org/sid/postgresql-9.0-pgfincore Thanks, I've taken a look. I did get everything working eventually--it's now available on http://pgxn.org/dist/debversion/ Not yet available in Debian due to dropping 8.4 compatibility; it'll go in once 9.1 is in unstable. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: [GENERAL] Using psql -f to load a UTF8 file
On Fri, Sep 21, 2012 at 09:21:36AM +0800, Craig Ringer wrote: > On 09/20/2012 11:44 PM, Leif Biberg Kristensen wrote: > > Torsdag 20. september 2012 16.56.16 skrev Alan Millington : > >>psql". But how am I supposed to remove the byte order mark from a UTF8 > >>file? I thought that the whole point of the byte order mark was to tell > >>programs what the file encoding is. Other programs, such as Python, rely > >>on this. > > > >http://en.wikipedia.org/wiki/Byte_order_mark > > > >While the Byte Order Mark is important for UTF-16, it's totally irrelevant to > >the UTF-8 encoding. > > I strongly disagree. The BOM provides a useful and standard way to > differentiate UTF-8 encoded text files from the random pile of > encodings that any given file could be. Use of the BOM in UTF-8 causes a host of display and interoperability problems, and is considered by many to be a broken practice. It's also pointless since there are no byte ordering issues with UTF-8. Best to not use it at all. In any case, the BOM byte sequence does not unambiguously identify UTF-8; it's equally valid for 8-bit charsets, so an external means of specifying the encoding is preferable and more robust. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Locale query
On Sat, Nov 28, 2009 at 09:46:18PM +1100, ad...@buydirect.net.au wrote: > Is everything ok with the above or something has gone wrong? I guess I > was expecting the locale command would show C instead of POSIX. The "C" and "POSIX" locales are one and the same thing. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
[GENERAL] Escaping input from COPY
Hi folks, In a Perl application I would like to frequently bulk load several hundred thousand rows of data into a temporary table before merging the contents into the database proper. I'm currently doing individual INSERTs into the temporary table, which has obviously got a significant performance penalty--the importing takes several minutes even on a very fast machine. I'd like to switch to COPY, which should be orders of magnitude faster. I see that DBD::Pg has an interface for this, which looks just fine. My problem is with how to escape the data. I need to use whatever escaping rules are in use by the server, which I've seen documented in the manual; but in order to cope with any future changes to these rules, and ensure identical behaviour, are there any standard functions I can use to escape the data before loading it? Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Escaping input from COPY
On Wed, Dec 21, 2011 at 06:16:42PM -0500, Josh Kupershmidt wrote:
> On Tue, Dec 20, 2011 at 7:47 PM, Adrian Klaver
> wrote:
> > As far as I know you did not get an answer, which is not the same as there
> > being
> > no answer:) I think you will find that the escaping is handled for you.
>
> I am rather dubious of the claim that "escaping is handled for you"
> with copy_from().
[...]
> This works because the strings have essentially been escaped by hand,
> and None turned into '\N'. So let's say you had the same data, without
> the escaping being done by hand, like this:
[...]
> But only because none of the rows happen to contain any characters
> which must be be escaped. How are you supposed to use copy_from() with
> arbitrary text, e.g.
>
> rows = [('Strange\t\tFirst\\Name', 'Last\nName', 100),
> ]
>
> because that sure doesn't seem to be handled automagically. Yes, I
> know I can write my own escaping code, but as Roger points out that's
> not ideal.
Yes, this is exactly the issue I have. Without being able to
handle the escaping of arbitrary data, it's too fragile to rely on.
At some point I'll get caught out by data containing escapes or
tabs, and it will all go horribly wrong.
I did see an example of using CSV format instead here:
http://www.perlmonks.org/?node_id=847265
and I'm sure there's a Pythonic equivalant which you could also use.
Since CSV has somewhat better-defined quoting rules (i.e. not
PostgreSQL-specific), I think I'll be trying this first. I'd be
happy to use the PostgreSQL format, but to avoid future breakage, I'd
need some way of determining what the server-side format is when
escaping.
If neither are sufficiently robust, I'll need to stick with
parameterised inserts, which handle arbitrary stuff without problems,
other than being slow.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Schema version control
On Thu, Feb 10, 2011 at 02:58:15PM -0700, Rob Sargent wrote: > On 02/10/2011 02:38 PM, Royce Ausburn wrote: > > My company is having trouble managing how we upgrade schema changes across > > many versions of our software. I imagine this is a common problem and > > there're probably some neat solutions that we don't know about. > > > > For the last 10 years we have been writing bash shell scripts essentially > > numbered in order db0001, db0002, db0003 The number represents the > > schema version which is recorded in the database and updated by the shell > > scripts. We have a template that provides all the functionality we need, > > we just copy the script and fill in the blanks. The schema upgrade > > scripts are committed to svn along with the software changes, and we have > > a process when installing the software at a site that runs the scripts on > > the DB in order before starting up the new version of the software. > > Don't the bash scripts get checked in to .../perforce/cvs/svn/git/...? > Aren't they part of the resources of the project(s)? I was thinking about this a little more. With the new CREATE EXTENSION functionality in Postgres, we have the infrastructure to run various SQL scripts to migrate between versioned states. Obviously the extension code relates to extensions such as datatypes. I was wondering if this is sufficiently generic that it could be used to migrate between different versions of a schema? This wouldn't be using the EXTENSION functionality, just the ability to run the scripts. This would enable easy upgrades (and downgrades, branching etc.) between different schema versions, providing that the appropriate scripts were installed. If this were optionally also accessible via an SQL syntax such as an analogue of CREATE and/or ALTER EXTENSION, it would provide a reliable and standardised method for installing and upgrading a schema, which would potentially prevent a great deal of wheel-reinvention between software packages. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] The scope of extensions
Hi folks, I'm a happy creator/user of extensions (e.g. my postgresql_debversion extension). But I'm wondering if they can be used for more than just simple types: - can an extension depend upon another extension? This would probably be implicit based upon the use of an object which belonged to another extension? (Are the META.json dependency metadata actually used at runtime?) - can relations just as tables, indexes, views and associated stuff such as triggers be included as part of an extension? Are there limits upon what may be part of an extension? The reason for the above is that I'd very much like to be able to version my entire application's schema using the extension mechanism (or something based upon the ideas in the extensions mechanism). Since SCHEMA is already taken, maybe CREATE/ALTER/DROP_APPLICATION. This would permit easy installation and upgrade of all the objects relating to a single application installed in the database. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] The scope of extensions
On Mon, Apr 16, 2012 at 10:22:19AM -0500, Merlin Moncure wrote: > On Mon, Apr 16, 2012 at 10:05 AM, Roger Leigh wrote: > > The reason for the above is that I'd very much like to be able to > > version my entire application's schema using the extension mechanism > > (or something based upon the ideas in the extensions mechanism). Since > > SCHEMA is already taken, maybe CREATE/ALTER/DROP_APPLICATION. This > > would permit easy installation and upgrade of all the objects relating > > to a single application installed in the database. > > not following that -- it sounds like you are trying to hook into the > grammar? that's something you can't do through an extension. but it's > an interesting thought to do application versioning through the > extension system...i'm pretty sure it hasn't been tried. there may be > some pitfalls though. This was mainly just speculative--in the case that the extension system didn't support everything I wanted, I was wondering if extending the grammar would be a viable approach; obviously it would require other work too! Every project I've worked on which uses PostgreSQL has independently implemented its own set of installation and upgrade scripts, which has typically included some form of table for storing the current schema version and other settings to allow the scripts to safely do their job. However, I'm not a big fan of unnecessary wheel reinvention, and if PostgreSQL could provide a standard mechanism for doing this which all applications could utilise, that would be (IMO) an absolutely fantastic feature. If extensions can be used as they stand to realise this, then that's absolutely great: the end user installation instructions can be reduced to CREATE EXTENSION myapplication; and the equivalent for upgrades. I'm not sure if another keyword would be useful in this context, since this is much more than a single extension, it's an entire schema. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] The scope of extensions
On Mon, Apr 16, 2012 at 09:20:14PM +0200, Guillaume Lelarge wrote: > On Mon, 2012-04-16 at 21:16 +0200, Guillaume Lelarge wrote: > > On Mon, 2012-04-16 at 16:46 +0100, Roger Leigh wrote: > > > On Mon, Apr 16, 2012 at 10:22:19AM -0500, Merlin Moncure wrote: > > > > On Mon, Apr 16, 2012 at 10:05 AM, Roger Leigh > > > > wrote: > > > > > The reason for the above is that I'd very much like to be able to > > > > > version my entire application's schema using the extension mechanism > > > > > (or something based upon the ideas in the extensions mechanism). > > > > > Since > > > > > SCHEMA is already taken, maybe CREATE/ALTER/DROP_APPLICATION. This > > > > > would permit easy installation and upgrade of all the objects relating > > > > > to a single application installed in the database. > > > > > > > > not following that -- it sounds like you are trying to hook into the > > > > grammar? that's something you can't do through an extension. but it's > > > > an interesting thought to do application versioning through the > > > > extension system...i'm pretty sure it hasn't been tried. there may be > > > > some pitfalls though. > > > > > > This was mainly just speculative--in the case that the extension > > > system didn't support everything I wanted, I was wondering if > > > extending the grammar would be a viable approach; obviously it would > > > require other work too! > > > > > > Every project I've worked on which uses PostgreSQL has independently > > > implemented its own set of installation and upgrade scripts, which > > > has typically included some form of table for storing the current > > > schema version and other settings to allow the scripts to safely do > > > their job. However, I'm not a big fan of unnecessary wheel > > > reinvention, and if PostgreSQL could provide a standard mechanism > > > for doing this which all applications could utilise, that would be > > > (IMO) an absolutely fantastic feature. If extensions can be used > > > as they stand to realise this, then that's absolutely great: the > > > end user installation instructions can be reduced to > > > CREATE EXTENSION myapplication; > > > and the equivalent for upgrades. I'm not sure if another keyword > > > would be useful in this context, since this is much more than a > > > single extension, it's an entire schema. > > > > Won't work if you care to save your database with pg_dump. Any tables > > created by extensions won't be saved with pg_dump. All you will get is a > > "CREATE EXTENSION myapplication;", and no data. > > Actually, I'm not completely right here. You may configure your > extension to allow your tables to be dumped. See > http://www.postgresql.org/docs/9.1/interactive/extend-extensions.html#AEN51978 > for details. > > IOW, it may work, but you need to be extra-careful. I don't know anyone > doing this right now. Thanks, I'll have a closer look at this. An equivalent to EXTENSION which did dump everything by default would be the ideal solution. I wonder how much work that would entail--I could take a stab at it if it's not insanely complex, and it's not considered absolutely insane. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Custom type, operators and operator class not sorting/indexing correctly
Dear all,
I've created a new domain (debversion) derived from TEXT, which
includes its own operators (< <= = >= > and <>), and also its
own operator class for BTREE indices.
The operators function correctly when I test them by themselves,
e.g. SELECT x < y;
However, if I create a table with a column of this type, ORDER BY
does not result in correct ordering. I have to explicitly add
'USING <' to the query, and even this fails to work if I haven't
defined the operator class:
# SELECT * FROM testv ORDER BY version ASC;
version
--
1.0.3-3
3.0.7+1-1
3.0.7+1-2
3.0.7+1-2~lenny2
(4 rows)
# SELECT * FROM testv ORDER BY version USING <;
version
--
1.0.3-3
3.0.7+1-1
3.0.7+1-2~lenny2
3.0.7+1-2
(4 rows)
The latter shows the correct ordering. The former appears to be
using the lexical ordering of the TEXT type. Adding an index
does not affect the ordering, even if I explictly make it use my
operator class (it's also set as the default).
The SQL code to create the type and demonstrate the problem follows
at the end of this mail. It requires the PL/Perl and PL/pgSQL
languages to be available. It shows example queries to demonstrate
the ordering issue above.
I thought that I had correctly defined the type, functions, operators
and operator class in order for everything to function correctly, but
I must be missing some final piece of the puzzle or some PostgreSQL
subtlety I'm not aware of (this is my first attempt at defining
operators, and I am also a newcomer to using procedural languages).
Could anyone suggest what I've done wrong here?
Many thanks,
Roger Leigh
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
--- WannaBuild Database Schema for PostgreSQL-*- sql -*-
--- Debian version type and operators
---
--- Code derived from Dpkg::Version:
--- Copyright © Colin Watson
--- Copyright © Ian Jackson
--- Copyright © 2007 by Don Armstrong
---
--- PostgreSQL SQL, PL/pgSQL and PL/Perl:
--- Copyright © 2008 Roger Leigh
---
--- This program is free software: you can redistribute it and/or modify
--- it under the terms of the GNU General Public License as published by
--- the Free Software Foundation, either version 2 of the License, or
--- (at your option) any later version.
---
--- This program is distributed in the hope that it will be useful, but
--- WITHOUT ANY WARRANTY; without even the implied warranty of
--- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
--- General Public License for more details.
---
--- You should have received a copy of the GNU General Public License
--- along with this program. If not, see
--- <http://www.gnu.org/licenses/>.
SET SESSION plperl.use_strict TO 't';
CREATE DOMAIN debversion AS TEXT;
COMMENT ON DOMAIN debversion IS 'Debian package version number';
ALTER DOMAIN debversion
ADD CONSTRAINT debversion_syntax
CHECK (VALUE !~ '[^-+:.0-9a-zA-Z~]');
-- From Dpkg::Version::parseversion
CREATE OR REPLACE FUNCTION debversion_split (debversion)
RETURNS text[] AS $$
my $ver = shift;
my %verhash;
if ($ver =~ /:/)
{
$ver =~ /^(\d+):(.+)/ or die "bad version number '$ver'";
$verhash{epoch} = $1;
$ver = $2;
}
else
{
$verhash{epoch} = 0;
}
if ($ver =~ /(.+)-(.*)$/)
{
$verhash{version} = $1;
$verhash{revision} = $2;
}
else
{
$verhash{version} = $ver;
$verhash{revision} = 0;
}
return [$verhash{'epoch'}, $verhash{'version'}, $verhash{'revision'}];
$$
LANGUAGE plperl
IMMUTABLE STRICT;
COMMENT ON FUNCTION debversion_split (debversion)
IS 'Split debian version into epoch, upstream version and revision';
CREATE OR REPLACE FUNCTION debversion_epoch (version debversion)
RETURNS text AS $$
DECLARE
split text[];
BEGIN
split := debversion_split(version);
RETURN split[1];
END;
$$
LANGUAGE plpgsql
IMMUTABLE STRICT;
COMMENT ON FUNCTION debversion_epoch (debversion)
IS 'Get debian version epoch';
CREATE OR REPLACE FUNCTION debversion_version (version debversion)
RETURNS text AS $$
DECLARE
split text[];
BEGIN
split := debversion_split(version);
RETURN split[2];
END;
$$
LANGUAGE plpgsql
IMMUTABLE STRICT;
COMMENT ON FUNCTION debversion_version (debversion)
IS 'Get debian version upstream version';
CREATE OR REPLACE FUNCTION debversion_revision (version debversion)
RETURNS text AS $$
DECLARE
split text[];
BEGIN
split := debversion_split(version);
RETURN split[3];
END;
$$
LANGUAGE plpgsql
IMMUTABLE STR
Re: [GENERAL] Custom type, operators and operator class not sorting/indexing correctly
On Wed, Jan 21, 2009 at 02:03:03AM -0500, Tom Lane wrote: > Roger Leigh writes: > > I've created a new domain (debversion) derived from TEXT, which > > includes its own operators (< <= = >= > and <>), and also its > > own operator class for BTREE indices. > > You can't realistically attach such things to a domain; try making > a separate type, perhaps with an implicit cast to text to allow > use of text operators for other purposes. Ah, thanks for the clarification. So I need to use CREATE TYPE rather than CREATE DOMAIN. Because I'm essentially just storing a text string with different operators, can I derive a type from TEXT (perhaps by reusing the same input, output, receive and send functions as TEXT?) I saw the textsend and textreceive functions, which I assume are the appropriate functions for send and receive? Are there any for input and output which I may reuse? Many thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Custom type, operators and operator class not sorting/indexing correctly
On Wed, Jan 21, 2009 at 08:52:19PM +0100, Martijn van Oosterhout wrote: > On Wed, Jan 21, 2009 at 10:48:09AM +0000, Roger Leigh wrote: > > Ah, thanks for the clarification. So I need to use CREATE TYPE > > rather than CREATE DOMAIN. Because I'm essentially just storing > > a text string with different operators, can I derive a type from > > TEXT (perhaps by reusing the same input, output, receive and send > > functions as TEXT?) I saw the textsend and textreceive functions, > > which I assume are the appropriate functions for send and receive? > > Are there any for input and output which I may reuse? > > Yes, you can copy all the existing attributes. Use: > > select * from pg_type where typname='text'; > > To get the relevent info (upcoming 8.4 will have CREATE TYPE xxx > (LIKE=text) ). Lookup the citext project for an example. Many thanks for this suggestion; it has been incredibly useful. Using a pre-existing C implementation, plus looking at citext for how to write the operators correctly, I now have a working pure C (C++ implementation). http://git.debian.org/?p=users/rleigh/sbuild.git;a=tree;f=db;h=0a6d3348744c59b78322ec6a4855876875613239;hb=81fd39259953853632a7d0e2198cfc745d270fe3 I just have a few points I'd like to clarify. In http://git.debian.org/?p=users/rleigh/sbuild.git;a=blob;f=db/debversion.cc;h=980786ecf7a3b7fb5769d04b0952af300723c3b9;hb=81fd39259953853632a7d0e2198cfc745d270fe3 debversioncmp (lines 49-73), I'm duplicating text* to char* by hand. Is the text_to_cstring available internally also accessible by external modules (I didn't see it in any headers)? After every PG_GETARG_TEXT_PP, I've called PG_FREE_IF_COPY before returning. However, I saw in citext (the behaviour of which I duplicated in debversion_smaller and debversion_larger (lines 221-246)) that you *don't* use PG_FREE_IF_COPY before returning one of the two values. Is this not a potential memory leak? Don't you need to duplicate your chosen value, then free both of the temporary values? I also noticed that I couldn't include some postgres headers in my code (e.g. ) due to included headers and using invalid C++ syntax due to use of "using" and "typename" which are reserved C++ keywords. The headers are also not wrapped with extern "C" blocks for direct inclusion in C++ sources, though this isn't as big a deal--you can just include them as I did within such a block in your own code. The former problem can't be worked around due to it being invalid code (this can be rectified by renaming to not use these specific keyword names). Many thanks for your help, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: [GENERAL] Custom type, operators and operator class not sorting/indexing correctly
On Sun, Jan 25, 2009 at 05:08:54PM +0100, Martijn van Oosterhout wrote: > On Sun, Jan 25, 2009 at 03:52:02PM +0000, Roger Leigh wrote: > > > > I'm duplicating text* to char* by hand. > > Is the text_to_cstring available internally also accessible by > > external modules (I didn't see it in any headers)? > > A function like that exists, the "proper" way to do it is (untested): > > DatumGetCString( DirectFunctionCall1(textout, TextGetDatum(foo) ) > > It's used in various places, in the unreleased 8.4 there will be > official functions like cstring_to_text and text_to_cstring. Many other > modules already declare stuff like this. Great, it looks like I'll be able to make things much simpler with 8.4, though I will need to be backward compatible with 8.3 for some time. > > After every PG_GETARG_TEXT_PP, I've called PG_FREE_IF_COPY before > > returning. However, I saw in citext (the behaviour of which I > > duplicated in debversion_smaller and debversion_larger (lines 221-246)) > > that you *don't* use PG_FREE_IF_COPY before returning one of the two > > values. Is this not a potential memory leak? Don't you need to > > duplicate your chosen value, then free both of the temporary values? > > Memory leaks are not an issue generally, everything you allocate gets > freed at the end of the statement, if not earlier. Normally you don't > manually free at all, however code that might be used by indexes is > somewhat of an exception, since they might be called often in a tight > loop. smaller/larger are not index functions, but the cmp function is. > > Though your strings here are probably short enough you won't notice > either way. Thanks for the clarification, I wasn't aware everything was automatically freed. The stricter requirements for index operators does make sense. > > I also noticed that I couldn't include some postgres headers in > > my code (e.g. ) due to included headers > > and using invalid C++ syntax > > C++ incompatability has been noted before and patches were posted. I > don't remember right now what happened to them, check the archives. Ah, thanks. I won't file a bug if it's already a known issue. Thanks again, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: [GENERAL] Pet Peeves?
On Fri, Jan 30, 2009 at 03:44:48PM -0800, rhubbell wrote: > On Fri, 30 Jan 2009 20:38:06 + > Gregory Stark wrote: > > > > > rhubbell writes: > > > > > Nope, had to find it in another package called libpq-dev. > > > That's on UbuntuHardy. Maybe it's a maintainer problem? > > > > > > What logic would lead someone to separate pg_config from everything else? > > > Do people often just install the server and nothing else? Then what? > > > > This is actually *required* by Debian/Ubuntu packaging rules. > > > > The development environment must be packaged separately from shared > > libraries > > like libpq or else major snafus arise when a new soversion of libpq comes > > out. > > You need to be able to have both versions installed simultaneously (in case > > you have programs which require both) but that won't work if they both > > contain > > things like header files or executables. > > Weren't .so born from a need to save disk space? Maybe startup speed too. > Now they're a PITA. Not really. You just need to ensure that you have the correct development environment for the version of PostgreSQL which you are targetting. While it might appear to be unnecessarily complex, you'll find that there's a very good reason for it. * Every library in Debian is split into separate runtime and development packages (and also documentation). * Users will only need the runtime. * Only developers and build dæmons will need to install the -dev packages). * Multiple -dev packages can and do exist for supporting multiple library versions, especially during transitions from one version to the next. They can't generally be installed simultaneously (conflicting files common to both such as pg_config), so you just install the one you require. This saves valuable diskspace on end-user systems as well as allowing for the creation of known sane build environments (look up how Debian uses Build-Depends for automated package building). > > > BTW I ran into the need for pg_config upon installing DBD::Pg. > > > Maybe DBD::Pg maintainer problem? > > > > Installing a package for DBD::Pg or building it? The former would indeed be > > a > > package bug. > > When I installed the package I did via CPAN so maybe this was my mistake. > Not every CPAN package is packaged for debian so I often times don't bother > checking if a perl module exists in debian I just do > perl -MCPAN -e 'install (DBD::Pg)' or whatever pkg It's always worth checking first (first line): % apt-cache search dbd | grep -i postgres libdbd-pg-perl - Perl DBI driver for the PostgreSQL database server libdbd-pg-ruby - Ruby/DBI PostgreSQL driver libdbd-pg-ruby1.8 - Ruby/DBI PostgreSQL driver for Ruby 1.8 libdbd-pgsql - PostgreSQL database server driver for libdbi postgresql-contrib-8.3 - additional facilities for PostgreSQL libaprutil1-dbd-pgsql - The Apache Portable Runtime Utility Library - PostgreSQL Driver libdbd-pg-ruby1.9 - Ruby/DBI PostgreSQL driver for Ruby 1.9 % apt-cache search 'dbd.*-perl' | grep -i postgres libdbd-pg-perl - Perl DBI driver for the PostgreSQL database server postgresql-contrib-8.3 - additional facilities for PostgreSQL Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: [GENERAL] Pet Peeves?
On Sat, Jan 31, 2009 at 10:10:01AM -0800, rhubbell wrote: > Thanks, using the same apt commands, try to find pg_config. Well, those commands search package names and metadata (including descriptions), and pg_config isn't mentioned so you won't find anything. Given that pg_config matches the version of postgresql you have installed, it's included in libpq-dev where you would expect (this is what all other library packages containing -config scripts do, though most have nowadays switched to using pkg-config and providing an associated .pc file). % dpkg -S $(which pg_config) libpq-dev: /usr/bin/pg_config Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
