June 2012 - database-devel

Postgresql enum type conversions
by Luke Hoersten 22 Jun '12

22 Jun '12

I'm trying to use postgresql enum types to represent Haskell types like in the code snippet below but an receiving the following error: "Incompatible {errSQLType = "x", errHaskellType = "Text", errMessage = "types incompatible"}" In other areas of my code (not shown) I'm successfully using Text to convert to and from Postgersql enum types but it doesn't seem to work in the case below. Any ideas what I'm doing wrong? Thanks, Luke import Database.PostgreSQL.Simple.FromField (FromField, fromField)import Database.PostgreSQL.Simple.FromRow (FromRow, field, fromRow)import Database.PostgreSQL.Simple.SqlQQ (sql) data X = X Float | Y Float buildX :: Text -> Float -> XbuildX "x" = XbuildX "y" = Y instance FromField (Float -> X) where fromField f v = buildX <$> fromField f v instance FromRow X where fromRow = field <*> (field :: RowParser Float)

2 1

Re: [database-devel] PGclear
by Leon Smith 09 Jun '12

09 Jun '12

You don't need to; PGclear is called automatically some time after the Result is garbage collected. This is done by using PQclear as a finalizer on the foreign pointer that represents a Result: http://hackage.haskell.org/packages/archive/postgresql-libpq/0.8.2/doc/html… There is "unsafeFreeResult", which triggers the finalizer at a deterministic point in time. But I don't recommend it's use unless you really understand the basics of GHC's implementation : you can easily have a reference to the Result sitting around in a thunk even "after" you have computed some value from the Result and thrown away all other references. (Because, in fact, you haven't computed the value completely; some part of that value is actually a thunk that needs the Result to compute the rest of the value.) And even then, I'm skeptical that very many applications would truly benefit from it's use. Best, Leon On Fri, Jun 8, 2012 at 3:03 PM, Kirk Peterson <necrobious(a)gmail.com> wrote: > Hi Leon, > > I'm working with your haskell postgresql-libpq package and noticed > that the examples form: > http://www.postgresql.org/docs/9.1/static/libpq-example.html > release a Result using the PGclear() function, however there is no > clear function in postgresql-libpq. > > I'm new to libpq in general, so perhaps this is an easy question: what > is the idiomatic way to clear a result using postgresql-libpq? > > > cheers, > -kirk > > -- > ⑆gmail.com⑆necrobious⑈ >

1 0

Re: [database-devel] UTCTime and Timestamp Without Time Zone
by Michael Snoyman 04 Jun '12

04 Jun '12

Thanks for the reference to November 18, 1883. That was an interesting read! I agree with your analysis of the situation with types. If this results in the need for breaking changes to persistent-postgresql, so be it. I'd rather have correctness than false stability. I looked at the code a bit, it looks good to me. On Jun 2, 2012 8:40 PM, "Leon Smith" <leon.p.smith(a)gmail.com> wrote:

3 2

UTCTime and Timestamp Without Time Zone
by Leon Smith 03 Jun '12

03 Jun '12

I've been reworking postgresql-simple's out-of-box support for time types, and as I've come to a better understanding of the issues involved, I've come to realize that I've made a small blunder. Namely, PostgreSQL's "timestamp without time zone" should not be automatically convertible to Data.Time.UTCTime. The "timestamp with time zone" type represents a clear, unambiguous point in time. It corresponds quite nicely to Data.Time.ZonedTime and Data.Time.UTCTime. By contrast, timestamp without time zone can only be understood in some larger context, specific to the application and perhaps even the particular instance of the application. And even with that context, it may turn out to be difficult (or impossible) to decide what point in time such a timestamp actually represents. This corresponds quite nicely to Data.Time.LocalTime. So, in essence, this conversion assumes that LocalTime are always UTCTime, and promoting an ambiguous time to an unambiguous type by assuming one particular time zone. So, do I plan on removing this conversion from postgresql-simple sometime in the near future. I do know that this impacts persistent-postgreql and may well impact others, but I think it's something that needs to be done. I do see that persistent-postgresql does have an upper bound set, so I will increment postgresql-simple's version to 0.2 when this functionality is removed. Part of the rework involves writing my own parsers and printers. These should prove to be significantly faster than those provided by Data.Time, but I don't have numbers yet. (and indeed, the printers aren't yet done.) Also, it introduces types to handle 'infinity' and '-infinity' timestamps and dates. And in the process of "reverse engineering" PostgreSQL's time format, I ended up doing a binary search by hand and discovered the date 1883-Nov-18, which has a particular significance to time geeks. So I've definitely learned some things in this process. Anyone who is interested in reviewing the work I've done so far should check out my "time" branch on github. I would appreciate feedback. https://github.com/lpsmith/postgresql-simple/tree/time Best, Leon

1 0